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

["Icarus Sparry" <isparry@Brocade.COM>]

> -----Original Message-----
> From: Michael Snyder [mailto:msnyder@specifix.com]
> Sent: Tuesday, April 15, 2008 11:05 AM
> To: Daniel Jacobowitz
> Cc: Icarus Sparry; gdb@sourceware.org
> Subject: Re: GDB doesn't display thread_id while debugging a core file
> 
> On Mon, 2008-04-14 at 23:10 -0400, Daniel Jacobowitz wrote:
> > On Mon, Apr 14, 2008 at 08:04:52PM -0700, Icarus Sparry wrote:
> > > 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
> > > machines.
> >
> > No.  You would have to rely on the native x86 library luckily doing
> > the right thing.
> 
> And that's highly unlikely.  Data structures would likely
> have different fields and sizes and such.
> 
> If someone wanted to make a project of building a cross-libthread-db,
> I'm sure it could be done -- but it would be a project.

I am obviously not making myself clear! It is "obvious" to me that one
needs a "cross-libthread-db" library, for example one that is an x86
executable but is configured to handle threading on a ppc32 with NPTL as
I described above. I do not expect things like this to come for free on
most systems. The question I hoped I had asked was "How much effort is
it?"

The program I am interested in at the moment only has a single __thread
variable, which is used to index many arrays. I have a number of
choices, ranging from write a function in gdb to get the value of this
particular variable, to fixing gdb so it can get the information
correctly from the core for all thread local variables. The latter is
going to be more work, but makes gdb a better debugger for everyone.