Re: RFC: %ebp-based backtrace patch

Michael Matz
2009-07-07T12:00:23Z

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.