From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6252 invoked by alias); 7 Jun 2005 13:10:38 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 6212 invoked by uid 22791); 7 Jun 2005 13:10:24 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 07 Jun 2005 13:10:24 +0000 Received: from drow by nevyn.them.org with local (Exim 4.50) id 1DfdqZ-0007tL-1O; Tue, 07 Jun 2005 09:10:23 -0400 Date: Tue, 07 Jun 2005 13:10:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: debugging threaded apps. thread ID missing in corefile. Message-ID: <20050607131022.GA30174@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , gdb@sources.redhat.com References: <200506061929.47871.abeach@deepvision.ca> <20050607000944.GA13192@nevyn.them.org> 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-06/txt/msg00060.txt.bz2 On Tue, Jun 07, 2005 at 06:46:13AM +0300, Eli Zaretskii wrote: > > Date: Mon, 6 Jun 2005 20:09:44 -0400 > > From: Daniel Jacobowitz > > Cc: gdb@sources.redhat.com > > > > On Mon, Jun 06, 2005 at 05:33:09PM -0500, Manoj Iyer wrote: > > > > > > Regarding debugging threaded apps, gdb does not display the pthread id (ID > > > returned by pthread_self() ) when reading information from a corefile. > > > > Yes. You can find information about this decision in the list > > archives. We need to use libthread_db.so.1 to retrieve thread IDs, and > > we do not have a graceful way to use it for only core dumps which > > belong to the native system (as opposed to sysrooted or cross core > > dumps). > > If this situation is not going to be changed RSN, I suggest to say > this in the manual. Any objections? No objection from me. I'm not planning to change it, because (a) thread IDs are mostly cosmetic, and (b) the cross-debugging case is more important to me than the native case. > Btw, the node "Threads" in the manual sounds at least a little > outdated: e.g., it only mentions Solaris and HP-UX as platforms > capable of supporting multi-threaded debuggees. Could someone in the > know please read that node and see if it needs to be updated in any > significant way? I just took a look at it; I think it's fine. It also mentions SGI and Lynx further down; the Lynx code is I think removed now, but still serves as a valid example here. > > > Where as when debugging the program live it is able to display the pthread > > > id (I dont know why the ID is a negative number, could be a bug?). > > > > Not really. The ID is a pointer above 0x80000000, used by the > > implementation. > > Well, then perhaps we should display the thread ID in hex? Hmm. I wouldn't object to this. The number is opaque to the user code; for LinuxThreads it is an encoded index into an array (usually between 0 and 64k; the first few threads are numbered around 32k and 16k). That looks plausible in hex or in decimal. For NPTL they are pointers and would look more plausible in hex. -- Daniel Jacobowitz CodeSourcery, LLC