Re: RFC: %ebp-based backtrace patch

[Michael Matz <matz at suse dot de>]

Hi,

On Mon, 6 Jul 2009, Mark Kettenis wrote:

> Makes sense to me.  If we have no clue where we are anymore, taking
> the gamble that %ebp is a valid frame pointer probably has better odds
> than that %esp points to a valid frame.  This will need a comment
> though.  I'll take care of that.
> 
> There is one potential problem though.  IIRC early versions of the
> vsyscall DSO did not have embedded debug information.

That was indeed quite some time ago, probably not useful to care anymore.  
But I took a quick look at the current implementations.  Some of them use 
%ebp frames, so those would be fine even without debug info (and broken 
with the current heuristic), and some use no frame at all (hence the 
heuristic of %esp-4 would work).  The latter will use the frame of the 
caller with the new heuristic, which is not ideal but somewhat okay when 
that caller itself has a %ebp frame.  If it hasn't, everything is off.  
All of that is problematic only for non-debug-info vsyscalls/vDSOs, which 
I'd hope don't exist in practice anymore.

One thing of note: we meanwhile use the Fedora package of gdb, mostly 
unchanged.  One patch of it interacts with the new heuristic, namely 
gdb-6.5-bz218379-ppc-solib-trampoline-fix.patch .  That patch isn't 
necessary anymore and in any case never really did what it intended.  The 
result of it is that the frame unwinder magically always finds a 
"function" (the fake minimal symbols for trampolines, not to be confused 
with "function@plt" symbols) for each program counter, even of length 
zero.  That breaks the heuristic again.


Ciao,
Michael.