From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22862 invoked by alias); 28 Mar 2014 13:00:00 -0000 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 Received: (qmail 22851 invoked by uid 89); 28 Mar 2014 12:59:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 28 Mar 2014 12:59:58 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 9FCA9116481; Fri, 28 Mar 2014 08:59:56 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id etJl3p8eiAs6; Fri, 28 Mar 2014 08:59:56 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 6669111640F; Fri, 28 Mar 2014 08:59:56 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id CAC95E079B; Fri, 28 Mar 2014 05:59:55 -0700 (PDT) Date: Fri, 28 Mar 2014 13:00:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: palves@redhat.com, gdb-patches@sourceware.org Subject: Re: [PATCH] Fix "PC register is not available" issue Message-ID: <20140328125955.GC4030@adacore.com> References: <83txawa9wk.fsf@gnu.org> <20140318161608.GD4282@adacore.com> <83pplja2h9.fsf@gnu.org> <20140318165413.GE4282@adacore.com> <834n2kztfw.fsf@gnu.org> <20140327125646.GA4030@adacore.com> <83k3bfy1ws.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83k3bfy1ws.fsf@gnu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-03/txt/msg00653.txt.bz2 > > it'd be interesting to understand why we send a TerminateProcess > > first, and then try to SetThreadContext later on. It does not seem > > to make sense. > > That happens because windows_kill_inferior does this: > > static void > windows_kill_inferior (struct target_ops *ops) > { > CHECK (TerminateProcess (current_process_handle, 0)); > > for (;;) > { > if (!windows_continue (DBG_CONTINUE, -1, 1)) > break; > if (!WaitForDebugEvent (¤t_event, INFINITE)) > break; > if (current_event.dwDebugEventCode == EXIT_PROCESS_DEBUG_EVENT) > break; > } > > target_mourn_inferior (); /* Or just windows_mourn_inferior? */ > } > > IOW, we resume the inferior (perhaps to collect all the debug > events?). I see - I didn't realize we were doing that, but a quick read of the corresponding MSDN page confirms that this is necessary: http://msdn.microsoft.com/en-us/library/windows/desktop/ms686714(v=vs.85).aspx > Given what I told above, what additional investigations are needed? > > Note that the second part is not entirely separate: those phantom > threads hit the problem with SetThreadContext as well, and checking > whether the thread already exited does let through fewer of those > warnings. In light of everything, I have no further comment at the moment regarding your latest patch. Perhaps one tiny detail: > + if (killed) > + SetThreadContext (th->h, &th->context); > + else > + CHECK (SetThreadContext (th->h, &th->context)); Rather than duplicate the call to SetThreadContext, perhaps another way of doing it would be: DWORD status; status = SetThreadContext (th->h, &th->context); if (!killed) CHECK (status) (not a strong suggestion, feel free to ignore) -- Joel