This is the mail archive of the
mailing list for the GDB project.
RE: GDB doesn't display thread_id while debugging a core file
- From: "Icarus Sparry" <isparry at Brocade dot COM>
- To: "Michael Snyder" <msnyder at specifix dot com>
- Cc: <gdb at sourceware dot org>
- Date: Mon, 14 Apr 2008 20:04:52 -0700
- Subject: RE: GDB doesn't display thread_id while debugging a core file
> -----Original Message-----
> From: Michael Snyder [mailto:email@example.com]
> Sent: Monday, April 14, 2008 6:24 PM
> To: Icarus Sparry
> Cc: firstname.lastname@example.org
> Subject: Re: GDB doesn't display thread_id while debugging a core file
> On Mon, 2008-04-14 at 18:01 -0700, Icarus Sparry wrote:
> > Last November there was some discussion on this topic, which ended
> > Daniel Jacobowitz saying in
> > http://sourceware.org/ml/gdb/2007-08/msg00068.html
> > 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.
> > Being able to access variables declared with __thread in core files
> > would certainly be useful. Could someone give some reasonable guess
> > the amount of effort required to do this? In particular for a
> > corefile from a linux process with NPTL being debugged on an x86
> > box.
> Off hand, I would not expect the libthread_db library to
> be able to do anything useful with a corefile from a different
If I understand what Daniel was saying correctly, the libthread_db file
would be an x86 shared library, but it would be configured to handle
ppc32 elf core files, in the same way as the executable
powerpc-linux-gdb program that currently we have running on the x86