Re: problem unwinding past pthread_cond_wait() on x86 RedHat 9.0

[Mark Kettenis <kettenis@chello.nl>]

   Date: Tue, 14 Oct 2003 12:02:20 -0400
   From: Daniel Jacobowitz <drow@mvista.com>

   > > How did it work in 5.3?  I'm assuming dumb luck, we unwound 0xfffffe02
   > > wrong.
   > 
   > With 5.3, it was "luck", if we can call it that way (the old backtrace
   > is incomplete too, and probably the value of some registers is not
   > unwound properly in some of the frames). I didn't look too closely, but
   > I think GDB 5.3 didn't handle 0xfffffe02 as a frameless function, and
   > therefore used %ebp to fetch the return address. The problem is that
   > this %ebp was the frame pointer from a caller two or three frames up...
   > So we ended up skipping these two or three frames.  And then after that,
   > it was business as usual...

   Ah, and pthread_cond_wait is frameless so that worked.  Hmmmmm.  If we
   get confused, falling back to trying %ebp wouldn't be an entirely bad
   idea.  Mark, does that seem plausible or is it just asking for
   problems?

It's tricky.  The point is that the unwinder tries very hard not to
get confused; only if it's certain that it has found code that sets up
a frame it uses %ebp.  Otherwise it assumes the function is frameless.
If we don't do it like this, we'll certainly miss some frames in some
fairly common cases, for example in many of the syscall stubs in
glibc.

Also note that for truly frameless code, %ebp can be used as a scratch
register, and therefore can't be trusted to contain a valid frame
pointer at all.

Mark