This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]