GDB support for thread-local storage

Andrew Cagney ac131313@cygnus.com
Sat Jun 22 08:22:00 GMT 2002


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

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

Andrew




More information about the Gdb mailing list