binaries: should step across helper functions

Needs triage. Reported by Bernard Ogden.

Generally speaking, GDB does not distinguish "helper functions from libgcc" in any particular way.

Default behaviour when using "step" on a function call site is: if the called function has debug information, step into it; if it does not, then step over it.

So if your expected behaviour is to step over libgcc helpers, then the way to achieve that is to remove (or not install) debug information for libgcc ...

Yep, that's what I was trying to ask for, though I may not have made it clear. Prebuilt toolchains from Linaro should exclude debug information for the helpers - or, also provide full stack unwind data (see bug 889985).

So given from the discussion in the other bug:
- you're using another debugger, so the discussion about GDB is not relevant
- you're statically linking in the libgcc helper in question, so installing debuginfo packages is not relevant

The only question is whether the static copy of libgcc.a your toolchain is using provides debug information.

However, I do not quite understand your last sentence. With GCC, if you ask for debug information, you will *always* get .debug_frame. If you strip debug info, it will always remove .debug_frame together with the other DWARF sections (.debug_info etc.). I do not see any (normal) way how you ever could end up with an object that has .debug_info but no .debug_frame ...

Can you run a "readelf -a" on the copy of libgcc.a you're using and provide the results (at least for the object containing the helper function in question)?

Correct, but DS-5's behaviour is similar to GDB's in this respect - steps into functions with debug info, steps over those without.

Relevant output follows:

File: /work/installs/sw/gcc/bin/../lib/gcc/arm-linux-gnueabi/4.6.2/libgcc.a(_arm_addsubsf3.o)
ELF Header:
  Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class: ELF32
  Data: 2's complement, little endian
  Version: 1 (current)
  OS/ABI: UNIX - System V
  ABI Version: 0
  Type: REL (Relocatable file)
  Machine: ARM
  Version: 0x1
  Entry point address: 0x0
  Start of program headers: 0 (bytes into file)
  Start of section headers: 1432 (bytes into file)
  Flags: 0x5000000, Version5 EABI
  Size of this header: 52 (bytes)
  Size of program headers: 0 (bytes)
  Number of program headers: 0
  Size of section headers: 40 (bytes)
  Number of section headers: 16
  Section header string table index: 13

Section Headers:
  [Nr] Name Type Addr Off Size ES Flg Lk Inf Al
  [ 0] NULL 00000000 000000 000000 00 0 0 0
  [ 1] .text PROGBITS 00000000 000034 00021c 00 AX 0 0 4
  [ 2] .data PROGBITS 00000000 000250 000000 00 WA 0 0 1
  [ 3] .bss NOBITS 00000000 000250 000000 00 WA 0 0 1
  [ 4] .note.GNU-stack PROGBITS 00000000 000250 000000 00 0 0 1
  [ 5] .ARM.attributes ARM_ATTRIBUTES 00000000 000250 000023 00 0 0 1
  [ 6] .debug_line PROGBITS 00000000 000273 00015c 00 0 0 1
  [ 7] .rel.debug_line REL 00000000 000a50 000008 08 14 6 4
  [ 8] .debug_info PROGBITS 00000000 0003cf 000104 00 0 0 1
  [ 9] .rel.debug_info REL 00000000 000a58 000020 08 14 8 4
  [10] .debug_abbrev PROGBITS 00000000 0004d3 000014 00 0 0 1
  [11] .debug_aranges PROGBITS 00000000 0004e8 000020 00 0 0 8
  [12] .rel.debug_arange REL 00000000 000a78 000010 08 14 11 4
  [13] .shstrtab STRTAB 00000000 000508 00008d 00 0 0 1
  [14] .symtab SYMTAB 00000000 000818 000190 10 15 12 4
  [15] .strtab STRTAB 00000000 0009a8 0000a7 00 0 0 1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

There are no section groups in this file.

There are no program headers in this file.

Relocation section '.rel.debug_line' at offset 0xa50 contains 1 entries:
 Offset Info Type Sym.Value Sym. Name
00000095 00000102 R_ARM_ABS32 00000000 .text

Relocation section '.rel.debug_info' at offset 0xa58 contains 4 entries:
 Offset Info Type S...

OK, thanks. The situation on a native Ubuntu install is that libgcc.a seems to be stripped completely, it does not contain any debug information.

However, when building libgcc.a manually without stripping it, I can confirm the same effect you show: on some (not all) libgcc objects, there is no .debug_frame even though we have .debug_info.

This seems clearly wrong to me. I'll have a look what's going on here ...

OK, found it. It's actually very simple: those routines are not generated by the compiler at all, but instead are provided directly as assembler files. This assembler code is missing proper annotations to generate DWARF CFI ...

CFI support was added to GAS in 2003-05 and enabled in ARM in 2004-10. The next release was 2.16 so the last five releases have had .cfi_function support.

Just for the record - the CodeSourcery GCC toolchain that I was using previously (their 2010.09-50 release, GCC 4.5.1) has a libgcc.a with no .debug_info sections in its objects - though some of them have .debug_frame. Which perhaps is odd, but at least explains the discrepant behaviour under debug.

Note that the problem doesn't show when cross-building but native testing, but does show when cross-building and testing under gdbserver.

(gdb) s
6 return a * (b + 5);
(gdb) s
__aeabi_fadd ()

finish works correctly on GDB.

Fix validated on gcc-linaro-arm-linux-gnueabi-2012.01-20120112+bzr2336~win32/ which I picked up from http://people.linaro.org/~michaelh/incoming/binaries/. DS-5 no longer steps in to the function where I observed the problem (__addsf3), which implies that .debug_info is no longer present.