GDB support for thread-local storage

Daniel Jacobowitz
Tue Jun 25 09:29:00 GMT 2002

On Tue, Jun 25, 2002 at 05:11:39PM +0100, James Cownie wrote:
> > 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
> 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.

That's what I meant by document.  If you look at libthread_db, you'll
see that it includes the internal header which describes the layout of
a thread descriptor.  Changes to that structure are not counted and I
don't think they'll like the idea.  They're also hard to identify,
since it draws types from other headers.

Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

More information about the Gdb mailing list