Re: GDB support for thread-local storage

[Daniel Jacobowitz <drow at mvista dot com>]

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

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