From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5790 invoked by alias); 19 May 2009 03:29:49 -0000 Received: (qmail 5781 invoked by uid 22791); 19 May 2009 03:29:48 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 19 May 2009 03:29:42 +0000 Received: (qmail 8764 invoked from network); 19 May 2009 03:29:40 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 19 May 2009 03:29:40 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFA] improved thread id reporting Date: Tue, 19 May 2009 03:29:00 -0000 User-Agent: KMail/1.9.10 Cc: Doug Evans References: <20090404184604.8524C1C759C@localhost> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905190429.38917.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-05/txt/msg00389.txt.bz2 On Tuesday 19 May 2009 00:23:15, Doug Evans wrote: > Ping. >=20 > Ok to check in? I haven't convinced myself yet that your normal_stop change always does what you want. Won't it print: [Switching from thread #0 to thread #3, 0x41001960 (LWP 14407)] ^ if the previosly selected thread happens to exit in a series of misfortunate events? Say,=20 thread 1 break foo thread 2 continue >=20 >=20 > On Thu, May 7, 2009 at 10:46 PM, Doug Evans wrote: > > Blech. =A0Right list this time. > > > > > > On Sun, Apr 5, 2009 at 8:33 PM, Daniel Jacobowitz wrot= e: > >> On Sun, Apr 05, 2009 at 01:36:06PM -0700, Doug Evans wrote: > >>> Attached is a simplistic patch to help illustrate the challenge. > >>> > >>> Here is an example session that prints from/to and the thread number > >>> in "[New ...", "[Switching ...", etc. messages. > >>> I can think of two issues with the patch: > >>> 1) Printing "[tT]hread" twice in one line is a bit annoying. > >>> 2) Spreading from/to over two lines is a bit annoying. > >> > >> What do you think of this? =A0On the theory that you can go look up > >> thread #2, either in 'info threads' or in a previous notification: > >> > >> [Switching from thread #2 to thread #3, Thread 0x41001960 (LWP 14407)] > > > > "works for me" > > > >> Or, migrating the "Thread" out: > >> > >> [Switching from thread #2 to thread #3, 0x41001960 (LWP 14407)] > >> > >> But that might be tricky with multi-process, some ptid_t's are not > >> threads. > > > > It's not clear how multi-process is going to work yet (or more likely > > I've forgotten). =A0I played with attaching and running several > > processes via gdbserver and all processes appear in "info threads". > > [sidebar: I wouldn't mind "info threads" just showing the threads of > > the current process, otherwise it might get confusing. =A0And given that > > "info inferiors" is used to show all the processes IWBN if "inferior > > N" switched to the specified process; a straightforward and intuitive > > mapping from "info threads" + "thread N".] > > > > How about this? > > >=20 --=20 Pedro Alves