From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22148 invoked by alias); 11 Jul 2008 13:21:47 -0000 Received: (qmail 22139 invoked by uid 22791); 11 Jul 2008 13:21:46 -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:21:29 +0000 Received: (qmail 4095 invoked from network); 11 Jul 2008 13:21:27 -0000 Received: from unknown (HELO guest-246.lvknet) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 11 Jul 2008 13:21:27 -0000 From: Vladimir Prus To: Pedro Alves Subject: Re: [MI non-stop 03/11, RFA] Discard cleanup when deferring displaced step Date: Fri, 11 Jul 2008 13:21:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb-patches@sourceware.org References: <200806282039.52280.vladimir@codesourcery.com> <200807111410.58951.pedro@codesourcery.com> In-Reply-To: <200807111410.58951.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807111721.24934.vladimir@codesourcery.com> 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/msg00191.txt.bz2 On Friday 11 July 2008 17:10:58 Pedro Alves wrote: > 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? Seems right to me. Should that be a separate patch, or should I adjust this one? - Volodya