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

[Daniel Jacobowitz <drow@mvista.com>]

On Tue, Oct 14, 2003 at 08:58:10AM -0700, Joel Brobecker wrote:
> > That's NPTL.  Are you sure you understand the problem right - I don't
> > have RH9's glibc here, only Rawhide's, but there's CFI for
> > pthread_cond_wait in Rawhide.
> 
> I can't say I'm 100% sure, but last time I checked, I couldn't find
> any CFI:
> 
>    % objdump --headers /lib/tls/libpthread.so.0 | grep frame
>     15 .eh_frame_hdr 0000002c  00009dc8  00009dc8  00009dc8  2**2
>     16 .eh_frame     0000010c  00009df4  00009df4  00009df4  2**2
> 
> No .debug_frame section (not a single dwarf2-related section for
> that matter).

That is CFI.  The .eh_frame section is actually just about the same as
the .debug_frame section, but encoded a little differently and loaded
into memory instead of marked as a debugging section.

However, 0x10c bytes is not encouraging for having unwind info for the
function in question.  In rawhide:
 15 .eh_frame_hdr 000001d4  0000bf10  0000bf10  0000bf10  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 16 .eh_frame     00000944  0000c0e4  0000c0e4  0000c0e4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA

> > So anyway this _will_ go away someday.
> 
> Yes, fortunately. I just suppose that the RH9.0 users will probably have
> to update their NPTL library if they want this to work...
> 
> > You really can't unwind past this sort of thing without either debug
> > info or frame pointers.
> 
> That was my feeling too. But having only a little experience in the
> area, I was wondering if there was any technique that I didn't know
> about.
> 
> > 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?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer