From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16879 invoked by alias); 7 Aug 2007 11:31:21 -0000 Received: (qmail 16857 invoked by uid 22791); 7 Aug 2007 11:31:19 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 07 Aug 2007 11:31:16 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 0C0D6982C5; Tue, 7 Aug 2007 11:31:16 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id E8BBC98296; Tue, 7 Aug 2007 11:31:15 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1IINHM-0006VN-Rr; Tue, 07 Aug 2007 07:31:12 -0400 Date: Tue, 07 Aug 2007 11:31:00 -0000 From: Daniel Jacobowitz To: Carlos Eduardo Seo Cc: gdb@sourceware.org Subject: Re: GDB doesn't display thread_id while debugging a core file Message-ID: <20070807113112.GA24874@caradoc.them.org> Mail-Followup-To: Carlos Eduardo Seo , gdb@sourceware.org References: <46B78405.9000706@linux.vnet.ibm.com> <20070806203310.GA17519@caradoc.them.org> <46B790BA.2040805@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46B790BA.2040805@linux.vnet.ibm.com> User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-08/txt/msg00068.txt.bz2 On Mon, Aug 06, 2007 at 06:20:58PM -0300, Carlos Eduardo Seo wrote: > > The thread ID is produced by NPTL's libthread_db library, > Yes, and this number is also an address, the thread pointer used to > access the TCB, as it is defined in the TLS definitions in the ABI. > So, there's no magic involved. :) That's incorrect. The fact that pthread_self, and thus libthread_db, use a pointer to the "struct pthread" as their thread ID is an internal implementation detail of NPTL, i.e. subject to change. That means it's the province of libthread_db. We don't have any flag to indicate that it will be the case unless we ask the library for the ID. For instance, if you do this then you'll start showing the TLS pointer as a thread ID for LinuxThreads applications. But they used a different numbering scheme. An architecture method to get at the thread pointer directly would still be useful, by the way - we've talked about that for accessing __thread variables without debug info. > > Now that most platforms have moved from LinuxThreads to NPTL, this > > might be worth another look. Opportunistically, sometimes we can use > > libthread_db and get sensible answers. > This may be a silly question, but, how can we use libthread_db in > order to get the thread ID from threads within a core file? If we assume that the host's libthread_db will either recognize the core file and do the right thing, or reject the core file, then we can write a small target layer that uses it on top of corelow.c in a similar way to how linux-thread-db.c / proc-service.c use linux-nat.c. It's just a matter of testing that on a couple of different setups, like LinuxThreads and cross debuggers, to see how it behaves. Or doesn't behave. -- Daniel Jacobowitz CodeSourcery