Re: GDB support for thread-local storage

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Jun 21, 2002 at 06:31:25PM -0400, Andrew Cagney wrote:
> 
> >>> I'd call the libthread_db
> >>>approach broken for this purpose (a little outside its design scope
> >>>perhaps).
> >
> >>
> >>I think it reflects limitations of the current libthread-db interface 
> >>rather than a broken approach.
> >
> >
> >I disagree... the concept of having a "libthread_db" with an interface
> >involves it being a target library, part of the system.  Unless you
> >change its "interface" to be a data file rather than code, it requires
> >access to a target in order to interpret target data.  That's my whole
> >objection to it.
> 
> 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.

Without imposing structure on that data, I don't think it'll ever be
possible to have a gdb/libthread-db.c.

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