This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 `' 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
clones too.

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.


Daniel Jacobowitz

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]