From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22038 invoked by alias); 6 Nov 2005 19:26:16 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 22030 invoked by uid 22791); 6 Nov 2005 19:26:14 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 06 Nov 2005 19:26:14 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EYq9b-0000fh-UF; Sun, 06 Nov 2005 14:26:12 -0500 Date: Sun, 06 Nov 2005 19:26:00 -0000 From: Daniel Jacobowitz To: B Mullins Cc: gdb@sourceware.org Subject: Re: Fwd: Thread Debugging - NPTL/PPC Message-ID: <20051106192611.GA2377@nevyn.them.org> Mail-Followup-To: B Mullins , gdb@sourceware.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-11/txt/msg00121.txt.bz2 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