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

[Joel Brobecker <brobecker@gnat.com>]

> 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).

> 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...

-- 
Joel