info threads

info threads

[John S. Yates, Jr.]

I have been implementing support for "info threads"
based on the stock 5.3 release.

For the qfThreadInfo message I return a list of the
addresses of all TCBs (thread control blocks) known
to our nucleus.  It turns out that some of these
live below the 2GB boundary and some above.  Only
those TCBs that do not appear to be negative are
displayed.  Why is this?

/john
--
John S. Yates, Jr.   508 665-6897 (voice)
Netezza Inc          508 665-6811 (fax)
200 Crossing Blvd.   Framingham, MA 01701

Re: info threads

[Andrew Cagney]

> I have been implementing support for "info threads"
> based on the stock 5.3 release.
> 
> For the qfThreadInfo message I return a list of the
> addresses of all TCBs (thread control blocks) known
> to our nucleus.  It turns out that some of these
> live below the 2GB boundary and some above.  Only
> those TCBs that do not appear to be negative are
> displayed.  Why is this?

GDB would be showing its UNIX roots. Something is likely assuming that 
any -ve is invalid.  Excatly what, I don't know.

Andrew

Re: info threads

[Daniel Jacobowitz]

On Tue, Dec 04, 2007 at 09:10:13AM -0800, Jim Blandy wrote:
> Just a thought: stripping doesn't remove the dynamic symbol table.
> I think GDB reads both the dynamic and static ELF symbol tables.
> If we could get the symbols libpthread_db needs into libpthread's
> dynamic symbol table, would that prevent stripping from breaking
> thread debugging?

The maintainers refused.  I tried this years ago.

-- 
Daniel Jacobowitz
CodeSourcery

Re: info threads

[Jim Blandy]

Michael Snyder <msnyder at specifix.com> writes:
> On Mon, 2007-12-03 at 13:29 -0800, Brian Budge wrote:
>> Thanks for the pointer.  This was on Gentoo Linux, and libpthread was
>> indeed stripped.  I recompiled glibc with FEATURES="nostrip", and
>> everything works great.
>
> You might let the Gentoo folks know that gdb thread debugging
> will not work if they ship that library stripped.

Just a thought: stripping doesn't remove the dynamic symbol table.
I think GDB reads both the dynamic and static ELF symbol tables.
If we could get the symbols libpthread_db needs into libpthread's
dynamic symbol table, would that prevent stripping from breaking
thread debugging?

Re: info threads

[Michael Snyder]

On Mon, 2007-12-03 at 13:29 -0800, Brian Budge wrote:
> Thanks for the pointer.  This was on Gentoo Linux, and libpthread was
> indeed stripped.  I recompiled glibc with FEATURES="nostrip", and
> everything works great.

You might let the Gentoo folks know that gdb thread debugging
will not work if they ship that library stripped.

Re: info threads

[Brian Budge]

Thanks for the pointer.  This was on Gentoo Linux, and libpthread was
indeed stripped.  I recompiled glibc with FEATURES="nostrip", and
everything works great.

Thanks again,
  Brian

On Dec 2, 2007 3:56 PM, Daniel Jacobowitz <drow@false.org> wrote:
> On Sun, Dec 02, 2007 at 03:09:04PM -0800, Brian Budge wrote:
> > Hi all -
> >
> > I'm having trouble with some of the threading interfaces of gdb.  For
> > instance, info threads prints nothing.  I have read that this means it
> > is not supported for my architecture, but I could have sworn it worked
> > before.  That being said, I switched over from x86 to x86_64 a few
> > months ago, so maybe it's just my failing memory.
>
> Architecture has nothing to do with this.  You didn't say, but I'm
> guessing you mean some distribution of GNU/Linux, right?  In that
> case, this usually means that your libpthread.so or ld.so have been
> stripped, and that separate debug files for them are not available.
>
> --
> Daniel Jacobowitz
> CodeSourcery
>

Re: info threads

[Daniel Jacobowitz]

On Sun, Dec 02, 2007 at 03:09:04PM -0800, Brian Budge wrote:
> Hi all -
> 
> I'm having trouble with some of the threading interfaces of gdb.  For
> instance, info threads prints nothing.  I have read that this means it
> is not supported for my architecture, but I could have sworn it worked
> before.  That being said, I switched over from x86 to x86_64 a few
> months ago, so maybe it's just my failing memory.

Architecture has nothing to do with this.  You didn't say, but I'm
guessing you mean some distribution of GNU/Linux, right?  In that
case, this usually means that your libpthread.so or ld.so have been
stripped, and that separate debug files for them are not available.

-- 
Daniel Jacobowitz
CodeSourcery

info threads

[Brian Budge]

Hi all -

I'm having trouble with some of the threading interfaces of gdb.  For
instance, info threads prints nothing.  I have read that this means it
is not supported for my architecture, but I could have sworn it worked
before.  That being said, I switched over from x86 to x86_64 a few
months ago, so maybe it's just my failing memory.

In any case, can someone confirm that this should or should not work
on x86_64?  Any leads on what I might do to fix this issue if it
should indeed work?

Thanks,
  Brian