From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17376 invoked by alias); 11 Jul 2008 13:11:30 -0000 Received: (qmail 17360 invoked by uid 22791); 11 Jul 2008 13:11:29 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 11 Jul 2008 13:11:02 +0000 Received: (qmail 2997 invoked from network); 11 Jul 2008 13:11:00 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 11 Jul 2008 13:11:00 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [MI non-stop 03/11, RFA] Discard cleanup when deferring displaced step Date: Fri, 11 Jul 2008 13:11:00 -0000 User-Agent: KMail/1.9.9 Cc: Vladimir Prus References: <200806282039.52280.vladimir@codesourcery.com> In-Reply-To: <200806282039.52280.vladimir@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807111410.58951.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: 2008-07/txt/msg00190.txt.bz2 A Saturday 28 June 2008 17:39:52, Vladimir Prus wrote: > My MI non-stop tests (coming later in the series) revealed a bug in > displaced stepping -- we fail to discard cleanup on an early exit path, > which caused a call to normal_stop at very unfortunate time -- when a > thread was running. > Ooops, my bad. Thanks for catching this! I think it would make sense to tag the thread as running at that point. In the point of view of the frontend, it is running, but internally, it is known to not be executing, until its turn in the displaced stepping request queue arrives. That is, the frontend should not allow inspecting this thread as if it was running already, and interrupting it should make it stop as soon as it tries to execute, not skip over it like ends up happening currently. To be clear, the user told the thread to resume, it just didn't resume immediatelly due to an internal implementation detail. (is_running (ptid) && !is_executing (ptid)) should be true at that early return. Not a serious issue to run to fix it (may need care if starting the displaced step on it ends up failing), but, Anyone disagrees in principle? > OK? > > - Volodya > > * infrun.c (resume): Discard cleanups on early exit path. > --- > gdb/infrun.c | 11 +++++++---- > 1 files changed, 7 insertions(+), 4 deletions(-) > > diff --git a/gdb/infrun.c b/gdb/infrun.c > index cf23c18..e803d1b 100644 > --- a/gdb/infrun.c > +++ b/gdb/infrun.c > @@ -964,10 +964,13 @@ a command like `return' or `jump' to continue > execution.")); && sig == TARGET_SIGNAL_0) > { > if (!displaced_step_prepare (inferior_ptid)) > - /* Got placed in displaced stepping queue. Will be resumed > - later when all the currently queued displaced stepping > - requests finish. */ > - return; > + { > + /* Got placed in displaced stepping queue. Will be resumed > + later when all the currently queued displaced stepping > + requests finish. */ > + discard_cleanups (old_cleanups); > + return; > + } > } > > if (step && gdbarch_software_single_step_p (gdbarch)) -- Pedro Alves