From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31256 invoked by alias); 19 Mar 2014 10:07:32 -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 31246 invoked by uid 89); 19 Mar 2014 10:07:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Mar 2014 10:06:58 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2JA6rW3018390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Mar 2014 06:06:53 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2JA6paF005281; Wed, 19 Mar 2014 06:06:52 -0400 Message-ID: <53296C3B.4040507@redhat.com> Date: Wed, 19 Mar 2014 10:07:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Eli Zaretskii CC: brobecker@adacore.com, gdb-patches@sourceware.org Subject: Re: [PATCH] Fix "PC register is not available" issue 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> In-Reply-To: <83ioraam9m.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-03/txt/msg00442.txt.bz2 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" ? 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. But I think GetThreadContext will indeed succeed for these threads. 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. 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. But it might be I'm missing something. I wonder whether schedlock.exp is passing on Windows/Cygwin cleanly. IMO, this whole SuspendThread business is ripe for simplification/cleanup. >> and if so, what's the thread's backtrace like. > > Why would we be interested in that info? 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). -- Pedro Alves