Re: Fwd: Thread Debugging - NPTL/PPC

[Daniel Jacobowitz <drow@false.org>]

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