Re: NPTL libthread_db changes for static debugging

[Roland McGrath <roland at redhat dot com>]

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

If that is just making gdb robust to changing ti_tid values zero->nonzero
for the same ti_lid, then it seems worth having regardless of the glibc
resolution.  Since all ti_tid is really used for today is display, it seems
to me it might as well be fully robust to whatever value it has at whatever
time.

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

Understood.  I tested __stack_user because it was easiest to code up.
I don't think it will be hard to test more closely for TLS initialization.

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

If the gdb change is a nonregressing robustness improvement with respect to
libthread_db behavior, might as well put it in without delay regardless, no?

I will commit my current patch for now.  It sounds like a gdb that doesn't
mind won't be hard to come by soon enough.  At some point before too long,
I'll take a crack at making the ti_tid=0->ptr transition happen at TLS
initialization instead of libpthread initializer completion.  


Thanks,
Roland