Re: GDB doesn't display thread_id while debugging a core file

[Daniel Jacobowitz <drow@false.org>]

On Mon, Aug 06, 2007 at 06:20:58PM -0300, Carlos Eduardo Seo wrote:
> > The thread ID is produced by NPTL's libthread_db library,
> Yes, and this number is also an address, the thread pointer used to
> access the TCB, as it is defined in the TLS definitions in the ABI.
> So, there's no magic involved. :)

That's incorrect.  The fact that pthread_self, and thus libthread_db,
use a pointer to the "struct pthread" as their thread ID is an
internal implementation detail of NPTL, i.e. subject to change.  That
means it's the province of libthread_db.  We don't have any flag to
indicate that it will be the case unless we ask the library for the ID.

For instance, if you do this then you'll start showing the TLS pointer
as a thread ID for LinuxThreads applications.  But they used a
different numbering scheme.

An architecture method to get at the thread pointer directly would
still be useful, by the way - we've talked about that for accessing
__thread variables without debug info.

> > Now that most platforms have moved from LinuxThreads to NPTL, this
> > might be worth another look.  Opportunistically, sometimes we can use
> > libthread_db and get sensible answers.
> This may be a silly question, but, how can we use libthread_db in
> order to get the thread ID from threads within a core file?

If we assume that the host's libthread_db will either recognize the
core file and do the right thing, or reject the core file, then we can
write a small target layer that uses it on top of corelow.c in a
similar way to how linux-thread-db.c / proc-service.c use linux-nat.c.

It's just a matter of testing that on a couple of different setups,
like LinuxThreads and cross debuggers, to see how it behaves.  Or
doesn't behave.

-- 
Daniel Jacobowitz
CodeSourcery