Re: NPTL libthread_db changes for static debugging

[Daniel Jacobowitz <drow at false dot org>]

On Mon, Jun 25, 2007 at 01:59:38AM -0700, Roland McGrath wrote:
> > 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.

Even worse.  It was in libpthread.so; the fake event that we both
agree is a horrible kludge was only generated in #ifndef SHARED.

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

Always, not just with breakpoints set early.  I can't guarantee this
for all versions - different releases of GDB have radically different
thread support - but it looks like GDB CVS and GDB 6.6 have only
cosmetic problems with your patch.  That's as good as it gets without
the nasty hack.

I have a patch for GDB that fixes staticthreads.exp with a patched
glibc and has no regressions with an unpatched glibc.

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

It affects all programs, because GDB stops as soon as libpthread.so is
loaded.  You're not checking whether TLS has been initialized, but
whether __stack_user has.  That doesn't happen until
__pthread_initialize_minimal, which does not happen until the
initializers for libpthread.so run.  GDB loads symbols before
initializers run (so that it can debug initializers).

Shall we go with your most recent patch, or should we look for a way
to test whether TLS has been initialized?  I think that would be
sufficient, but the symbol would need to live in ld.so.  Please let me
know and I'll take care of the GDB patch before GDB 6.7.

-- 
Daniel Jacobowitz
CodeSourcery