From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20688 invoked by alias); 5 Apr 2009 18:50:33 -0000 Received: (qmail 20572 invoked by uid 22791); 5 Apr 2009 18:50:32 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 05 Apr 2009 18:50:26 +0000 Received: from spaceape24.eur.corp.google.com (spaceape24.eur.corp.google.com [172.28.16.76]) by smtp-out.google.com with ESMTP id n35IoMZP024345 for ; Sun, 5 Apr 2009 19:50:22 +0100 Received: from rv-out-0708.google.com (rvfc5.prod.google.com [10.140.180.5]) by spaceape24.eur.corp.google.com with ESMTP id n35IoKAj020644 for ; Sun, 5 Apr 2009 11:50:21 -0700 Received: by rv-out-0708.google.com with SMTP id c5so1590676rvf.24 for ; Sun, 05 Apr 2009 11:50:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.45.16 with SMTP id x16mr976934rvj.290.1238957420002; Sun, 05 Apr 2009 11:50:20 -0700 (PDT) In-Reply-To: <20090405011134.GA15762@caradoc.them.org> References: <20090404184604.8524C1C759C@localhost> <200904041904.n34J4UXV013513@brahms.sibelius.xs4all.nl> <20090405011134.GA15762@caradoc.them.org> Date: Sun, 05 Apr 2009 19:22:00 -0000 Message-ID: Subject: Re: improved thread id reporting From: Doug Evans To: 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/msg00064.txt.bz2 On Sat, Apr 4, 2009 at 6:11 PM, Daniel Jacobowitz wrote: > On Sat, Apr 04, 2009 at 03:17:02PM -0700, Doug Evans wrote: >> > 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? > > IMO, yes. =A0I don't think we need more settable options for details of > output formatting; 98% or so of users will use the default, so that's > the part that matters. Oh well, 2 out of 3 ... [Modulo one could provide a command to look up the pthread id given the thread number, or provide an option to "info threads" to include or not include it. I'm just mentioning that for completeness sake though.] Question: Why does remote.c print pid.tid? [ref: remote_pid_to_str] [I know I said it's kinda nice, but I still have a question.] IOW, if printing pid is good for remote.c then why isn't it good for non-re= mote? And if it's not good for non-remote, then why is it good for remote? [I'm specifically referring to the linux case, but I'm guessing the same applies to any gdbserver situation where one _could_ debug locally as well.] In the linux case at least the difference doesn't seem warranted (except as some compromise, but why compromise?). windows-nat.c:windows_pid_to_str, for example, prints pid.hex-tid. In the windows case is pid the same for every thread? (in the non-multiprocess case) Is there a case (windows or otherwise) where pid _could_ be different for different threads in the non-multiprocess case? I'd expect not (gdb pretty much assumes ptid.pid is the same for all threads in a process, right?), but please let me know if I'm wrong. So if one were to start over, it seems like the printing of the pid for every thread is better left to something else ("info proc pid" or some such? If "proc" has too much of a linux connotation (/proc, et.al.) then maybe "info inferior pid"? And if something like that makes sense, can we remove the printing of pid from multi-threaded target_pid_to_str's and remote_pid_to_str? It seems like the pretty-printing of a ptid_t is not a property of the target, per se (to the extent that all else being equal there doesn't seem to be a justification for printing local linux ptids different from remote linux ptids - I gather there was an implementation problem in communicating remote pthread_t's over the remote protocol, but I'm guessing what's there now is a compromise and not the preferred choice). I can't think of an existing place to move target_pid_to_str though. Blech. And there's nothing else on the target stack for remote_pid_to_str to defer to; IWBN if we could somehow teach it to print what the local version would print.