This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: GDB support for thread-local storage
- From: James Cownie <jcownie at etnus dot com>
- To: gdb at sources dot redhat dot com
- Date: Tue, 25 Jun 2002 17:11:39 +0100
- Subject: Re: GDB support for thread-local storage
> You'll never get them to document interface changes in pthreads'
> internal data structures. You're welcome to try if you like pain
> more than I do. The only layer the glibc folks support for
> accessing this data is thread_db.
I'm not sugggesting that they document it, rather that they provide a
version symbol which tells you which version of the pthreads code you
have, and then name libthread_db with a name which includes the
version number.
All I'm after is that one can tell from a debugger which version of
the pthread library one is looking at and then deduce which
libthread_db.so to dlopen.
Something as trivial as
static volatile int __pthread_version_number = 123;
somwehere would probably do.
The documentation requirement would be
The static symbol __pthread_version_number gives the version number
of the pthread library to allow a debugger to locate the appropriate
version of libthread_db.
and that's it. It doesn't change...
Thought they need to remember to change the version number when they
make changes which affect libthread_db.
-- Jim
James Cownie <jcownie@etnus.com>
Etnus, LLC. +44 117 9071438
http://www.etnus.com