From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8954 invoked by alias); 10 Jun 2009 16:20:34 -0000 Received: (qmail 8946 invoked by uid 22791); 10 Jun 2009 16:20:33 -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; Wed, 10 Jun 2009 16:20:27 +0000 Received: (qmail 28292 invoked from network); 10 Jun 2009 16:20:24 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Jun 2009 16:20:24 -0000 From: Pedro Alves To: Joel Brobecker Subject: Re: Fixes for a couple of infrun bugs (thread hop, revert to step thread). Date: Wed, 10 Jun 2009 16:20:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org References: <200905272300.28249.pedro@codesourcery.com> <20090609195807.GA25703@adacore.com> In-Reply-To: <20090609195807.GA25703@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906101721.33039.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-06/txt/msg00259.txt.bz2 On Tuesday 09 June 2009 20:58:07, Joel Brobecker wrote: > Coming late on this discussion: > > > + /* If the stepping thread exited, then don't try reverting > > + back to it, just keep going. We need to query the target > > + in case it doesn't support thread exit events. */ > > I'm just wondering if it would make sense to explain why you need to do > that in the comment, or perhaps just explain what would happen if you > didn't. There is such a nice description in the body of your email, and > I'm thinking it's worth having a short summary in the code. > > WDYT? > Sure! > (yes, I know, I'm a comments freak) Something like this? Or were you thinking on some different aspect of the issue? Let me know and I'll cook something extra. 2009-06-10 Pedro Alves * infrun.c (handle_inferior_event): Update comment around trying to revert back to a stepping thread that has exited. --- gdb/infrun.c | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) Index: src/gdb/infrun.c =================================================================== --- src.orig/gdb/infrun.c 2009-06-10 16:48:24.000000000 +0100 +++ src/gdb/infrun.c 2009-06-10 17:18:20.000000000 +0100 @@ -3496,9 +3496,25 @@ infrun: BPSTAT_WHAT_SET_LONGJMP_RESUME ( return; } - /* If the stepping thread exited, then don't try reverting - back to it, just keep going. We need to query the target - in case it doesn't support thread exit events. */ + /* If the stepping thread exited, then don't try to switch + back and resume it, which could fail in several different + ways depending on the target. Instead, just keep going. + + We can find a stepping dead thread in the thread list in + two cases: + + - The target supports thread exit events, and when the + target tries to delete the thread from the thread list, + inferior_ptid pointed at the exiting thread. In such + case, calling delete_thread does not really remove the + thread from the list; instead, the thread is left listed, + with 'exited' state. + + - The target's debug interface does not support thread + exit events, and so we have no idea whatsoever if the + previously stepping thread is still alive. For that + reason, we need to synchronously query the target + now. */ if (is_exited (tp->ptid) || !target_thread_alive (tp->ptid)) {