This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: backtrace() vs. _Unwind_Backtrace()


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]