Re: NPTL libthread_db changes for static debugging

[Roland McGrath <roland at redhat dot com>]

Sorry for the delay.

> On Wed, May 16, 2007 at 08:05:18PM -0700, Roland McGrath wrote:
> > I think these two problems make the zero-threads interface a nonstarter.
> 
> Your version of a zero-threads approach was more aggressive about
> claiming the thread ID didn't exist, since you keyed off libpthread's
> initialization rather than TLS initialization, and it didn't offer a
> creation event for clients to discover the first thread - I really did
> go round the alternatives several times before posting my patch.  With
> those I think it's feasible.

I am open to different solutions, but I really don't want to do something
that feels too kludgey, and the fake creation event does.

> But that's not the important difference between the two patches,
> anyway.  What really seems to make a difference was the nasty hack I
> used to only apply the fix to static executables.  It's hard to
> not change behavior in a way that confuses GDB.

Which nasty hack was that and was it in libthread_db, or in gdb?  If all
plans touch gdb, then it isn't much of a reason to choose one.

> This patch, like the other, breaks existing GDBs.  I set up a board
> file which uses glibc from a separate prefix, and ran the gdb
> testsuite with that and an unpatched GDB.  A number of thread lists
> end up containing the main thread twice, once with its original thread
> ID and once with its final thread ID.  Nothing seems to crash, though.

So this makes the test suite regress, and will sometimes produce slightly
confusing output for users (but maybe only if they had breakpoints set too
early?).  If that is as bad is it gets, it doesn't sound so terrible.

> Can we guarantee that the fake thread ID returned will always be zero
> (which GDB conveniently uses to mean "not threaded" already)?  If so,
> I can handle this basically the same as before, except that this time
> I'll be able to enable event reporting.  But I'll need to detect a
> change in thread ID for an already known LWP and delete the old
> "thread".

Yes, it's always zero.  Before TLS initialization, when the kernel leaves
nonzero garbage in the thread register (perhaps only non-setuid ia64),
td_thr_tlsbase may try to use the garbage pointer.  But that is never used
as the ti_tid value.

> Up to you whether the duplicate thread is acceptable for every
> released GDB.

It probably just is.  Noone has to deploy this libthread_db soon if they
don't want to.  If the impact is common, we can keep the change out of any
2.6.1 release.  Will it always get confused?  Or just it it had some
special reason to stop and contemplate threads too early on?  I'm figuring
that it won't matter at all for the normal case of dynamic linking where
ld.so is doing TLS setup early (so by the first time td_ta_new can succeed,
there is already no problem).  If it only affects statically linked
programs, where previously thread IDs and TLS were just never available,
then that certainly seems acceptable.


Thanks,
Roland