backtrace() vs. _Unwind_Backtrace()

Andrew Haley aph@redhat.com
Fri Dec 5 17:13:00 GMT 2003


David Mosberger writes:
 > >>>>> On Fri, 5 Dec 2003 10:46:47 +0000, Andrew Haley <aph@redhat.com> said:
 > 
 >   Andrew> David Mosberger writes:
 >   >> While debugging another problem, I noticed that libjava currently
 >   >> attempts to use libc's backtrace() function to create a stack
 >   >> trace (libjava/gnu/gcj/runtime/natStackTrace.cc).  Recently,
 >   >> libgcc got an _Unwind_Backtrace() function, which I think should
 >   >> do exactly what's needed there (in combination with
 >   >> _Unwind_GetIP()), so I think it would make sense to switch to
 >   >> _Unwind_Backtrace() instead.
 > 
 >   Andrew> Java uses backtrace() a lot, and _Unwind_Backtrace() is
 >   Andrew> inefficient.  I see no good reason to switch unless
 >   Andrew> backtrace() doesn't work on a given target.
 > 
 > But in that case, HAVE_BACKTRACE should be turned on for ia64 Linux.

Good.

 > Older versions of libc have a broken backtrace() on that platform,
 > but even that can be worked around by doing:
 > 
 > 	LD_PRELOAD=/usr/lib/libunwind-ia64.so.1
 > 
 > and with newer versions of libc, backtrace() will use _Unwind_Backtrace().

But we need to build a version of libgcj for ia64 Linux that works
without needing a special LD_PRELOAD.

Perhaps some configury that detects a new libc would be appropriate.

 > (And the libunwind-based _Unwind_Backtrace() is probably about as efficient
 > as it gets.)

Fine, but that doesn't address the common x86 case.  There, we have an
efficient backtrace(), and switching to _Unwind_Backtrace() without
libunwind would be a performance regression.  

Andrew.



More information about the Java mailing list