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

[msnyder at sonic dot net]

Daniel writes:
> 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.

Agree with Daniel.  This is an abi spec.  We are not allowed
to presume that we know the internal details of implementation.
That is what the libthread_db API is for.

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

Daniel, I think it's even simpler than that.

libthread_db works via callbacks to gdb that do nothing more
complicated than read memory.  GDB can read memory from the corefile.

The only question is whether the versions of libthread and
libthread_db match, on the host and (corefile-generating) target.

If they do, "it should just work" (tm).

And if there is a version string somewhere in the library's read/write
memory sections, it should also exist in the corefile.

Michael