From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31650 invoked by alias); 4 Apr 2009 22:17:12 -0000 Received: (qmail 31642 invoked by uid 22791); 4 Apr 2009 22:17:11 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 04 Apr 2009 22:17:06 +0000 Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id n34MH4mE008608 for ; Sat, 4 Apr 2009 15:17:04 -0700 Received: from rv-out-0708.google.com (rvbk29.prod.google.com [10.140.87.29]) by wpaz21.hot.corp.google.com with ESMTP id n34MH2Lg022955 for ; Sat, 4 Apr 2009 15:17:03 -0700 Received: by rv-out-0708.google.com with SMTP id k29so1323024rvb.44 for ; Sat, 04 Apr 2009 15:17:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.45.16 with SMTP id x16mr528237rvj.33.1238883422488; Sat, 04 Apr 2009 15:17:02 -0700 (PDT) In-Reply-To: <200904041904.n34J4UXV013513@brahms.sibelius.xs4all.nl> References: <20090404184604.8524C1C759C@localhost> <200904041904.n34J4UXV013513@brahms.sibelius.xs4all.nl> Date: Sat, 04 Apr 2009 22:24:00 -0000 Message-ID: Subject: Re: improved thread id reporting From: Doug Evans To: Mark Kettenis Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true 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/msg00053.txt.bz2 On Sat, Apr 4, 2009 at 12:04 PM, Mark Kettenis wr= ote: >> Date: Sat, =A04 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? =A0I'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. Ok, "very low" is subjective and context dependent. > 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. Realized. >> 2) When switching to a thread IWBN to also report the thread being switc= hed >> =A0 =A0from, otherwise one has to scrollback through the session to find= it >> =A0 =A0(assuming that's even possible). > > That's not an unreasonable suggestion. > >> 3) When reporting thread ids the only usable number in the gdb session >> =A0 =A0(gdb's internal thread number) is not included. > > I don't consider this to be a big issue. =A0If 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. =A0I'd expect that to be much > more convenient than scrollback through the session ;) I've sometimes had to manually search the output of "info threads" and map from pthread-id/lwp to gdb number when the source of the pthread-id/lwp was the "[New ...]" or "[Switching ...]" message. Blech. > 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. Even as a user-settable option?