Re: backtrace() vs. _Unwind_Backtrace()

[Andrew Haley <aph at redhat dot com>]

David Mosberger writes:
 > >>>>> On Fri, 5 Dec 2003 17:27:58 +0000, Andrew Haley <aph@redhat.com> said:
 > 
 >   Andrew> Given that we have to maintain such a mechanism, we should
 >   Andrew> default to the fastest working backtrace on each system.
 > 
 >   Andrew> In the case of the ia64, the fastest working backtrace is
 >   Andrew> _Unwind_Backtrace().
 > 
 > Actually, if you're going that route, the preference for ia64 linux
 > should be:
 > 
 > 	(1) backtrace() if its working fine
 > 	(2) _Unwind_Backtrace() otherwise

Right.

 > The reason is because:
 > 
 >  - libc's backtrace() is either broken or calls into _Unwind_Backtrace()
 >  - libunwind provides a correct and performance-optimal backtrace() and
 >    will be the one that gets picked up by newer versions of GCC
 >  - the _Unwind_Backtrace() interface is less efficient by design than
 >    backtrace() (since it requires a callback per frame)

Ah, I see.  I falsely assumed that, performance wise, there would be
no difference on this target,

 > I hope this isn't too confusing.  But my point is that if you need to
 > support both backtrace() and _Unwind_Backtrace() anyhow, for ia64
 > linux we should be using backtrace(), if it works correctly (which
 > should be easy to check via autoconf).

How?  I can't think of any easy way to see if a target machine's
backtrace() will work.

 > On the topic of backtrace performance: I'm always looking for good
 > test-cases that stress performance.  Can you suggest a good
 > artificial or real-world Java test-program that is sensitive to
 > backtrace() performance?

Not yet, beacuse we I think don't have a fully working security
infrastructure for libgcj.

Andrew.