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

> -----Original Message-----
> From: Michael Snyder [mailto:msnyderspecifix.com]
> Sent: Tuesday, April 15, 2008 11:05 AM
> To: Daniel Jacobowitz
> Cc: Icarus Sparry; gdbsourceware.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. 

On Tue, Apr 15, 2008 at 01:16:41PM -0700, Icarus Sparry
wrote:
> 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. 

We've talked about accessing __thread storage without
passing through
libthread_db.  In my opinion, that is likely to be a better
solution.
However, it's a bit tricky to figure out the module numbers
assigned
by the C library in this case...

-- 
Daniel Jacobowitz
CodeSourcery