binaries: can't step out of helper functions

Reported by Bernard Ogden.

Could you elaborate on the system environment where you're seeing this problem (in particular, exact version of the libgcc and gdb packages)?

Generally speaking, GDB tries three methods to unwind the stack:

- DWARF Call Frame Information records
This is the most precise method (correct at every IP), but it is only available if you have debugging info. In a default Ubuntu installation, all system libraries *have* debug info, but it is stripped off into a separate debuginfo package, which is not installed by default.

- ARM exception table entries
This is usually correct (except if your current IP is within function prologue or epilogue code), but it is only available if required for C++ exception handling: that is, if the function is not a leaf function, and if it is either compiled as C++ or as C with the -fexceptions flag. [ Note that I do not think the ARM ABI requires anything more than that. Could you elaborate on which document you're consulting? The "ARM ABI" is a family of multiple documents, and in none of them I found a section 2.1.1 ... ]

- Prologue parsing (i.e. reading the assembler instructions at function start)
This is not always reliable, but usually a pretty good heuristic. If this does not work for a frequently used system library function, we can (and should) always work on improving that heuristic ... That's why I'd like to know the specific details so I can have a look.

The context for this is evaluation of an initial 'prebuilt Linaro toolchain' drop from Michael Hope. My debugger is ARM's DS-5 rather than GDB - so far as I know it only uses the first method that you mention.

I can't tell you exactly how it was built, but it came from http://people.linaro.org/~michaelh/incoming/gcc-linaro-arm-linux-gnueabi-4.6-2011.09-1.tar.bz2 and arm-linux-gnueabi-gcc --version says 'arm-linux-gnueabi-gcc (Linaro 2011.09+bin1) 4.6.2 20110908 (prerelease)'.

The ABI document I am looking at is 'DWARF for the ARM Architecture' which can be found at http://infocenter.arm.com/help/index.jsp under 'ARM software development tools->Application Binary Interface->DWARF for the ARM Architecture' - a direct link that might work is http://infocenter.arm.com/help/topic/com.arm.doc.ihi0040a/IHI0040A_aadwarf.pdf. The relevant section does say 'obligations on producers of relocatable files' - I'm seeking confirmation of exactly what is meant by that in this case.

The target system that I'm running on is a years old filesystem built within ARM, but __addsf3 was statically linked in my test case so I think that the target system is not relevant in this case and anyway not so relevant for you as I'm not using GDB. Feel free to correct me.

As with bug 889984, this might be an issue for the folks building the prebuilt toolchain deliverable rather than the gcc maintainers.

OK, thanks. So the DWARF ARM ABI document says:
"To support stack unwinding by debuggers, producers must always generate .debug_frame sections"

This is not actually the case for the GNU/Linux toolchain. On all platforms, including ARM, the .debug_frame section is always generated *if* debug information is requested (i.e. the -g command line option is present), but not otherwise. In addition, a .debug_frame section that may have been present will be stripped when using the "strip" or similar commands.

On other platforms, there is another section .eh_frame with very similar contents to .debug_frames that is treated specially: on many platforms, it will be unconditionally generated; and it will never be stripped. However, ARM does not use .eh_frame. (Instead, it uses .ARM.exidx / .ARM.extbl, but those are quite different and not generated unconditionally either in any case.)

It might be worthwhile to look into implementing that special ARM requirement by having GCC always produce .dwarf_frame, and having "strip" refuse to remove it, when on ARM. This would be for the ARM GCC maintainers to investigate and decide.

In any case, however, the helper routines in libgcc *are* compiled with debug information initially. So if this is not present, it must have been stripped somehow in the build process of that particular pre-built toolchain you have. Michael, since you apparently provided that binary toolchain -- do you know how exactly it was built?

On the meaning of 'relocatable' - if we take this to mean 'ELF object has type ET_REL' then __addsf3 should have unwind info to conform to the doc.

Whether this really breaks with the ABI or not, having the information is useful when debugging.

@Ulrich: these are built using crosstool-NG. It's a fairly basic configuration of GCC and doesn't have an explicit strip step that I know of.

You may have answered this in the other bug: the floating point routines are hand-written assembler and don't include CFI frames.

Note that GDB with gdbserver correctly steps out if you tell it to 'finish'. Bernie isn't using GDB though.

@Ulrich: You stated some way above:
"It might be worthwhile to look into implementing that special ARM requirement by having GCC always produce .dwarf_frame, and having "strip" refuse to remove it, when on ARM. This would be for the ARM GCC maintainers to investigate and decide."

Could you point me at where this should be raised?

>Could you point me at where this should be raised?

I'd suggest the GCC mailing list (<email address hidden>), CC'ing the relevant maintainers (Richard Earnshaw, Ramana Radhakrishnan).