> Consider the attached test program. When built with -g in sparc64-*-*
> the resulting binary contains:
>
> - A .eh_frame segment containing CFA information for __libc_csu_init and
> __libc_csu_fini.
>
> - A .debug_frame segment containing CFA information for func2, func1 and
> main.
>
> The backtrace(3) implementation for sparc contains a simple unwinder
> that works well in most cases, but that unwinder is not used if
> libgcc_s.so can be dlopened and it provides _Unwind_Backtrace. Now,
> _Unwind_Backtrace uses .eh_frame but not .debug_frame. Thus,
> backtrace(3) is only useful in programs built with
> -fasynchronous-unwind-tables even if -g provides CFA info in
> .debug_frame.
How does that work for e.g. PowerPC or MIPS? Why not do the same for SPARC?
The glibc PowerPC port doesn't use the libgcc_s unwinder to implement
backtrace(). It has a little ad-hoc unwinder.
MIPS is like x86_64: it exclusively relies on libgcc_s _Unwind_Backtrace
to unwind the stack.
As far as I can tell, -fasynchronous-unwind-tables is disabled in MIPS
by default. Therefore unless -fasynchronous-unwind-tables is used at
build time backtrace() probably has the same problem than sparc (can't
tell for sure, as I don't have access to any mips host where to test).
