backtrace() vs. _Unwind_Backtrace()

Mon Dec 8 12:54:00 GMT 2003

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.