From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7458 invoked by alias); 19 May 2009 03:39:59 -0000 Received: (qmail 7450 invoked by uid 22791); 19 May 2009 03:39:58 -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:39:54 +0000 Received: (qmail 14791 invoked from network); 19 May 2009 03:39:52 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 19 May 2009 03:39:52 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFA] improved thread id reporting Date: Tue, 19 May 2009 03:39:00 -0000 User-Agent: KMail/1.9.10 Cc: Doug Evans References: <20090404184604.8524C1C759C@localhost> <200905190429.38917.pedro@codesourcery.com> In-Reply-To: <200905190429.38917.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200905190439.50707.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/msg00390.txt.bz2 On Tuesday 19 May 2009 04:29:38, Pedro Alves wrote: > On Tuesday 19 May 2009 00:23:15, Doug Evans wrote: > > Ping. > >=20 > > Ok to check in? >=20 > I haven't convinced myself yet that your normal_stop change always > does what you want. Won't it print: >=20 > [Switching from thread #0 to thread #3, 0x41001960 (LWP 14407)] > ^ >=20 > if the previosly selected thread happens to exit in a series > of misfortunate events? Say,=20 Following a fork is also a case where the previously thread may be long gone from the thread list when you get here. Note that I contructed the contrived case below, because delete_thread refuses to delete inferior_ptid from the thread list. There are several options here: make a better effort at storing the previous thread id; printing something about previous thread having exited; or (ugly?) documenting this #0 thing. I do have my reservations about being always possible to print a sensible previous thread id. >=20 > thread 1 > break foo thread 2 > continue > > > >=20 > >=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 wr= ote: > > >> 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 t= hat > > > "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 >=20 >=20 --=20 Pedro Alves