backtrace() vs. _Unwind_Backtrace()

[David Daney]

Andrew Haley wrote:

>David Daney writes:
>
> > The approach for the MIPS port of libgcj is to include a backtrace() 
> > replacement that calls _Unwind_Backtrace().  This works because 
> > backtrace() is a weak symbol in glibc.  It sounds like this is 
> > essentially what you are suggesting.
>
>If libc's backtrace starts to work on all systems we can deprecate
>calling _Unwind_Backtrace() directly.  But in the meantime, with
>broken backtrace() on several targets, we have to do whatever
>workarounds are necessary.
>
>The nice thing about _Unwind_Backtrace() is that it works on a wide
>range of targets.  Unfortunately, it doesn't work on all targets, so
>we'll need to maintain a mechanism for using either backtrace() or
>_Unwind_Backtrace().
>
>Given that we have to maintain such a mechanism, we should default to
>the fastest working backtrace on each system.
>
>In the case of the ia64, the fastest working backtrace is
>_Unwind_Backtrace().
>  
>
That was my intention with sysdep/dwarf2-backtrace.cc. It is a simple 
glue function, a very light weight wrapper to _Unwind_Backtrace() that 
presents the standard backtrace() API.  If it is omitted from libgcj 
(via configure magic) then the version from the c library will be used 
instead.

David Daney.