From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20850 invoked by alias); 19 Mar 2014 16:24:31 -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 20792 invoked by uid 89); 19 Mar 2014 16:24:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout27.012.net.il Received: from mtaout27.012.net.il (HELO mtaout27.012.net.il) (80.179.55.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Mar 2014 16:24:29 +0000 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0N2O00G00YNMLS00@mtaout27.012.net.il> for gdb-patches@sourceware.org; Wed, 19 Mar 2014 18:21:46 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N2O00EC6YSA0030@mtaout27.012.net.il>; Wed, 19 Mar 2014 18:21:46 +0200 (IST) Date: Wed, 19 Mar 2014 16:24:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH] Fix "PC register is not available" issue In-reply-to: <53296C3B.4040507@redhat.com> To: Pedro Alves Cc: brobecker@adacore.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83a9cm9mwr.fsf@gnu.org> References: <83txawa9wk.fsf@gnu.org> <20140318161608.GD4282@adacore.com> <83pplja2h9.fsf@gnu.org> <20140318165413.GE4282@adacore.com> <83k3bra0rx.fsf@gnu.org> <5328835C.4010908@redhat.com> <83ioraam9m.fsf@gnu.org> <53296C3B.4040507@redhat.com> X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00461.txt.bz2 > Date: Wed, 19 Mar 2014 10:06:51 +0000 > From: Pedro Alves > CC: brobecker@adacore.com, gdb-patches@sourceware.org > > On 03/19/2014 03:40 AM, Eli Zaretskii wrote: > >> Date: Tue, 18 Mar 2014 17:33:16 +0000 > >> From: Pedro Alves > >> CC: Joel Brobecker , gdb-patches@sourceware.org > >> > >> I see that the GetThreadContext call (do_windows_fetch_inferior_registers) > >> doesn't check for errors (I think it should (*)). It'd be interesting to know whether gdb can > >> actually read the registers off of this thread > > > > How to see those registers? > > Just "info registers" ? That's what I thought, but ... > If we can't even read registers off of it, and GetThreadContext > is failing, it means after your patch we'll be showing bogus > register contents for these threads. ...how do you tell bogus register contents from correct contents? It's not like I know which register should have what value at any given time, do I? > But I think GetThreadContext will indeed succeed for these threads. Well, at least MSDN begs to differ: You cannot get a valid context for a running thread. Use the SuspendThread function to suspend the thread before calling GetThreadContext. > AFAIK, we don't really need the SuspendThread calls when handling > a debug event, given that when WaitForDebugEvent returns a > stop event, all threads have already been stopped by the OS for us. Yes, AFAIK that's true. > We really only need to SuspendThread threads when we might want > to leave most threads paused on the next resume, for e.g., when > stepping over a breakpoint. The suspend count handling in > windows-nat.c is quite messy, and looking at the code, it doesn't > look like we actually get that right, given we only SuspendThread > threads if we try to read their registers, and so if nothing reads > registers off all threads when e.g., handling a breakpoint that > we decide needs to be stepped over (which we don't), then we end > up resuming threads we shouldn't. That's assuming that stepping resumes threads. I'm not sure, but I really don't know enough about debugging APIs on Windows. > It'll likely show us the thread is stopped at some ntdll.dll function > or some such, and from the function name we will likely > be able to infer what/which thread is this, like, e.g., whether > it's a thread injected with DebugBreakProcess or some such > (internally by one of the system dlls or the dlls your app > links with). I'll see what I can find about that, but I doubt you'd see something telltale in the backtrace. (The thread started by Windows for debugging is not part of this issue; I never saw the threads that are to have any debug-related functions on their callstacks.)