This is the mail archive of the
mailing list for the glibc project.
Re: NPTL libthread_db changes for static debugging
On Sun, May 13, 2007 at 03:40:27PM -0700, Roland McGrath wrote:
> > GDB (nptl_db) has feeling the threading is turned on as `nptl_version' symbol
> > already exists (as if `libpthread.so.0' would get loaded) due to `-static'.
> > That time still the %fs/%gs (or ia64 %r13) register has value 0.
> > Therefore nptl_db tries to read `struct pthread' from address 0 and fails.
> Please describe this in terms of the libthread_db interface contract.
> I take it the current situation is that before initialization in a
> static executable, td_ta_map_lwp2thr returns TD_ERR? This also makes
> td_ta_thr_iter return TD_ERR. Is that right?
I believe so. Of course they may or may not return TD_ERR; it depends
what happens when they do their bogus read.
> If the gdb changes Daniel described have gone in,
The last one hasn't; I was waiting for feedback on the glibc patch.
I've updated it for head GDB now though.
> Daniel's proposed libc patch generates a fake thread-create event after
> initialization. I don't like that. AFAICT, it's not really necessary
> at all. gdb can try thread_db operations any time it wants, to get
> th_unique if it's available at a later stop. If nothing else, it will
> get the thread-create event for the first pthread_create call (second
> thread). All that's really required is that before initialization is
> complete, td_* calls return a coherent error code indicating harmless
> uninitializedness (TD_NOTHR) rather than "generic error". Is that right?
I tried this, and it was almost sufficient.
A minor difference between our approaches was that you made the
iterate call return TD_NOTHR instead of TD_OK for successfully
iterating over zero threads. Your choice is more proper, but GDB had
to be taught that TD_NOTHR wasn't a fatal error.
The bigger problem is that we can not enable event reporting for
pthread_create until after we know the thread's ID (since NPTL checks
THREAD_SELF->report_events). GDB also uses PTRACE_EVENT_CLONE to
detect clones, so it can recover, but it seems to me that you should
be able to use libthread_db in this way without having to track
So, if you commit this I can make GDB work with it and have done so
locally for testing; but it seems abstractly unsatisfactory.
It also causes a few problems in the GDB testsuite; it breaks TLS
support because we decide we're dealing with a non-threaded program.
This happens because we get TD_NOTHR even in the dynamic case. GDB
stops after shared libraries are loaded but before their constructors
run to add their symbols (that's a feature - lets you debug the
constructor). So when we get to main we still think we have a single
threaded program. The right solution to this will depend on
what you think about the event notification problem, so I did not
work around it yet.
Consequently this patch would break existing GDBs.