GDB support for thread-local storage

[Andrew Cagney]

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

Andrew