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?
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?