Re: GDB support for thread-local storage

[Daniel Jacobowitz <drow at mvista dot com>]

On Sat, Jun 22, 2002 at 11:22:49AM -0400, Andrew Cagney wrote:
> >Sorry, I'm lost here.
> >>
> >>Say, instead of a libthread_db, we had gdb/libthread-db.c which could be 
> >>compiled on all systems.  It would have some sort of procedural 
> >>interface, and would grub around in target data to find thread X lwp 
> >>maps.  However, it could be written in a way that was host architecture 
> >>netural.
> >
> >
> >Sure.  But the design of libthread_db says, "I am 100% coupled to the
> >private structure of this thread implementation.  I must match its
> >version exactly if you want predictable results.  My details can change
> >in minor revisions or even more frequently."  That's not part of the
> >implementation; it's more like the purpose of the design.  It is a
> >layer between implementation-specific details with no guaranteed
> >structure and a structured client interface.
> 
> Right.
> 
> But what is stopping us picking up that code, compiling it on the host 
> (not target), and then using it in GDB?

Version skew primarily.  If you examine the way that libthread_db works
in GNU libc, you'll see that it knows the offset to various private
data structures by including the internal linuxthreads implementation
header.  These can change between minor point-releases of glibc.  We
could detect the version string and have lists of offsets that way but
it would mean updating GDB for every new version of glibc.  This is
probably feasible but mitigates the value of thread_db greatly; the
principal advantage was separating the debugger from knowledge of the
threads implementation.  We'd have to build target data structures (the
way that C++ ABI support does) and their types can vary greatly
architecture to architecture.  If we require libpthread.so to contain
debugging information it would be a little more practical, maybe...

On Solaris this isn't even an option of course.  If we don't use the
system libthread_db we have no way to duplicate its functionality.

> >Without imposing structure on that data, I don't think it'll ever be
> >possible to have a gdb/libthread-db.c.
> 
> We'll never be able to have a single libthread-db.c file but we should 
> at least be able to get the interface defined, and the code implemented, 
> in a way that makes it possible for it to be used on the host.

Perhaps for a limited set of (target arch, target lib version) pairs.

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