info threads

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

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

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

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.

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?

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