Fwd: Thread Debugging - NPTL/PPC

Fwd: Thread Debugging - NPTL/PPC

[B Mullins]

I have two boards, one is a ppc, one is a ppc64.  On both boards I
have 32 bit libs.  Using the exact same libs and binaries on the ppc
as the ppc64, gdb on the ppc64 works fine, where as gdb on the ppc
fails to track threads.  It seems in thread_db_new_objfile, gdb always
falls through with TD_NOLIBTHREAD.

I've compiled the latest GDB for both boards, my newly compiled
version of gdb fails to track threads for both boards.  Thus, I now
have a functional and a broken gdb for the ppc64.  My original intent
was to step through gdb on both boards looking for the point of
failure.

I've compared with LD_DEBUG=files for both the broken gdb and the
working gdb on the ppc64, the same libs are loaded in both cases. The
libc being using in both cases is NPTL enabled.

What information could I provide that would allow someone to point me
towards the correct place to look for the point of failure?

 Much Thanks,
 -Billy

Re: Fwd: Thread Debugging - NPTL/PPC

[Daniel Jacobowitz]

On Sun, Nov 06, 2005 at 01:52:21PM -0500, B Mullins wrote:
> I have two boards, one is a ppc, one is a ppc64.  On both boards I
> have 32 bit libs.  Using the exact same libs and binaries on the ppc
> as the ppc64, gdb on the ppc64 works fine, where as gdb on the ppc
> fails to track threads.  It seems in thread_db_new_objfile, gdb always
> falls through with TD_NOLIBTHREAD.
> 
> I've compiled the latest GDB for both boards, my newly compiled
> version of gdb fails to track threads for both boards.  Thus, I now
> have a functional and a broken gdb for the ppc64.  My original intent
> was to step through gdb on both boards looking for the point of
> failure.
> 
> I've compared with LD_DEBUG=files for both the broken gdb and the
> working gdb on the ppc64, the same libs are loaded in both cases. The
> libc being using in both cases is NPTL enabled.
> 
> What information could I provide that would allow someone to point me
> towards the correct place to look for the point of failure?

You need to find out why thread_db is failing to find the thread
libraries.

(A) Does GDB recognize that shared libraries, including the pthread
library, have been loaded?  "info shared" should show that not only are
the libraries listed, but also symbols were automatically loaded.

(B) What symbols does libthread_db try to look up (by calling
ps_pglobal_lookup), and which ones fail?  Some failing is OK.  All
failing is not OK.  A stripped libpthread.so won't work for NPTL
debugging; it needs the .symtab symbol table, although it doesn't need
debug information.

(C) Does ps_get_thread_area get called?  If so, does it fail?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Fwd: Thread Debugging - NPTL/PPC

[B Mullins]

Thank you!

> (B) What symbols does libthread_db try to look up (by calling
> ps_pglobal_lookup), and which ones fail?  Some failing is OK.  All
> failing is not OK.  A stripped libpthread.so won't work for NPTL
> debugging; it needs the .symtab symbol table, although it doesn't need
> debug information.
>

My libpthread was stripped, but I had the debug symbols stored in a
separate file.  In some cases the debug symbols were being found, in
other cases they were not being found.  I was able to use 'set
debug-file-directory' to direct gdb to the debug symbols, as well as I
was able to move the symbols to a suitable location for gdb to find
them by its lonesome.

I kept thinking that I didn't have stripped libs because of the case
where gdb was working as usual. It just happened, in that case, gdb
was able to find the debug symbols.

Thanks again!

Re: Fwd: Thread Debugging - NPTL/PPC

[Daniel Jacobowitz]

On Sun, Nov 06, 2005 at 05:51:30PM -0500, B Mullins wrote:
> Thank you!
> 
> > (B) What symbols does libthread_db try to look up (by calling
> > ps_pglobal_lookup), and which ones fail?  Some failing is OK.  All
> > failing is not OK.  A stripped libpthread.so won't work for NPTL
> > debugging; it needs the .symtab symbol table, although it doesn't need
> > debug information.
> >
> 
> My libpthread was stripped, but I had the debug symbols stored in a
> separate file.  In some cases the debug symbols were being found, in
> other cases they were not being found.  I was able to use 'set
> debug-file-directory' to direct gdb to the debug symbols, as well as I
> was able to move the symbols to a suitable location for gdb to find
> them by its lonesome.
> 
> I kept thinking that I didn't have stripped libs because of the case
> where gdb was working as usual. It just happened, in that case, gdb
> was able to find the debug symbols.

Thanks for closing the loop.  I've been thinking about ways to make
this failure mode more obvious; all too many people have trouble
getting it to work.

-- 
Daniel Jacobowitz
CodeSourcery, LLC