Re: GDB support for thread-local storage

Daniel Jacobowitz
2002-06-22T05:59:30Z

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