From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26716 invoked by alias); 4 Apr 2009 19:21:44 -0000 Received: (qmail 26708 invoked by uid 22791); 4 Apr 2009 19:21:43 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 04 Apr 2009 19:21:36 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id EBDD0107D1; Sat, 4 Apr 2009 19:21:33 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id B970C107C8; Sat, 4 Apr 2009 19:21:33 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1LqBQq-0007Li-8v; Sat, 04 Apr 2009 15:21:32 -0400 Date: Sat, 04 Apr 2009 20:40:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: dje@google.com, gdb@sourceware.org Subject: Re: improved thread id reporting Message-ID: <20090404192132.GA28232@caradoc.them.org> Mail-Followup-To: Mark Kettenis , dje@google.com, gdb@sourceware.org References: <20090404184604.8524C1C759C@localhost> <200904041904.n34J4UXV013513@brahms.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904041904.n34J4UXV013513@brahms.sibelius.xs4all.nl> User-Agent: Mutt/1.5.17 (2008-05-11) 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: 2009-04/txt/msg00050.txt.bz2 On Sat, Apr 04, 2009 at 09:04:30PM +0200, Mark Kettenis wrote: > > Date: Sat, 4 Apr 2009 11:46:04 -0700 (PDT) > > From: dje@google.com (Doug Evans) > > > > Hi. > > > > GDB's current reporting of thread ids has (at least) three problems (IMO): > > 1) Reporting the pthread id (e.g. 0x0xf7e5cbb0) has a very low S/N ratio. > > Uh? I'd say it has a very high S/N ratio; it's the only thing that > you can actually use to identify a thread to a particular thread > created by the code you're debugging. > > Also realize that whatever is printed now between () is OS-specific > information that varies from OS to OS and may even be completely > absent in the case of user-level threads libraries. I agree with Mark. I think the existing IDs are quite handy. > > 2) When switching to a thread IWBN to also report the thread being switched > > from, otherwise one has to scrollback through the session to find it > > (assuming that's even possible). > > That's not an unreasonable suggestion. Agreed, although I'm curious what people think of "to X from Y" vs "from Y to X" - I found your sample visually confusing. > > 3) When reporting thread ids the only usable number in the gdb session > > (gdb's internal thread number) is not included. > > I don't consider this to be a big issue. If I need a GDB internal > thread number, I find it no problem to just use the "info threads" > command and make decisions based on that. I'd expect that to be much > more convenient than scrollback through the session ;) > > That said, if it's possible to print them without creating additional > line breaks on an 80-column wide screen, I have no objections. I'd find these helpful. -- Daniel Jacobowitz CodeSourcery