backtrace() vs. _Unwind_Backtrace()

[Andrew Haley]

Bryce McKinlay writes:
 > On Dec 7, 2003, at 12:21 AM, Andrew Haley wrote:
 > 
 > > I don't want it to sound like I'm opposed to the approach of calling
 > > _Unwind_Backtrace() directly.  It sounds quite a clean idea.  However,
 > > not every architecture supports DWARF2, and if we have a new
 > > architecture for unwinding we need to support those targets too.
 > 
 > The thing is, backtrace() alone doesn't help us much. Without DWARF2, 
 > we can't find the start of the function, and can't lookup the 
 > Class/Method. So why bother?

All we need is a method that maps pc->name.  We know that we can use
addr2line to do that, and we are about to get a demangler that we can
link into libgcj.

 > > I am also not keen on checking in a performance regression at this
 > > stage in 3.4.  It might be that the cost of
 > > _Unwind_FindEnclosingFunction is so much higher than that of unwinding
 > > the stack that the difference vanishes into the noise.  I don't know.
 > 
 > I don't know either, but I would guess that the linear searching done 
 > to find the FDE is a major reason why the _Unwind_ functions are slow. 

Which linear search do you mean?  We should be using a binary search
now, at least within each object.  We were using a linear search for a
while because the DWARF info for libffi was incomplete.

 > As part of an _Unwind_Backtrace, we can use _Unwind_GetRegionStart 
 > instead of _Unwind_FindEnclosingFunction - this avoids looking each FDE 
 > twice.

That's a sensible optimization.

Andrew.