This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GDB support for thread-local storage


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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]