From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12313 invoked by alias); 4 Apr 2009 19:06:05 -0000 Received: (qmail 11882 invoked by uid 22791); 4 Apr 2009 19:06:01 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 04 Apr 2009 19:05:56 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id n34J4Vkp013868; Sat, 4 Apr 2009 21:04:31 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id n34J4UXV013513; Sat, 4 Apr 2009 21:04:30 +0200 (CEST) Date: Sat, 04 Apr 2009 19:07:00 -0000 Message-Id: <200904041904.n34J4UXV013513@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: dje@google.com CC: gdb@sourceware.org In-reply-to: <20090404184604.8524C1C759C@localhost> (dje@google.com) Subject: Re: improved thread id reporting References: <20090404184604.8524C1C759C@localhost> 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/msg00047.txt.bz2 > 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. > 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. > 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. > To fix (1) I'd like to simply remove the pthread id from the output. I think that's a bad idea.