This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: NPTL libthread_db changes for static debugging
- From: Roland McGrath <roland at redhat dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: Jan Kratochvil <jan dot kratochvil at redhat dot com>, libc-alpha at sourceware dot org
- Date: Mon, 25 Jun 2007 23:46:34 -0700 (PDT)
- Subject: Re: NPTL libthread_db changes for static debugging
> 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