From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26850 invoked by alias); 28 Mar 2014 17:49:19 -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 26838 invoked by uid 89); 28 Mar 2014 17:49:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS 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; Fri, 28 Mar 2014 17:49:17 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s2SHnFSm014423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Mar 2014 13:49:15 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s2SHnDBp028512; Fri, 28 Mar 2014 13:49:14 -0400 Message-ID: <5335B619.6040605@redhat.com> Date: Fri, 28 Mar 2014 17:49: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> <834n2kztfw.fsf@gnu.org> <53358C37.9050907@redhat.com> <83a9cafcpz.fsf@gnu.org> In-Reply-To: <83a9cafcpz.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-03/txt/msg00668.txt.bz2 On 03/28/2014 05:35 PM, Eli Zaretskii wrote: >> Date: Fri, 28 Mar 2014 14:50:31 +0000 >> From: Pedro Alves >> CC: Joel Brobecker , gdb-patches@sourceware.org >> >> On 03/26/2014 06:49 PM, Eli Zaretskii wrote: >>> This describes the results of my looking into this issue, given the >>> comments and suggestions by Joel and Pedro. Sorry about the length. >>> >>>> I didn't mean to change the behavior - only hide the warning. >>>> In this case, if it is normal that we can't suspend the thread, >>>> then there is no point in warning (scaring) the user about it. >>>> I would only generate a warning if something abnormal that we should >>>> fix occured. >>> >>> The patch near the end of this message indeed includes code to ignore >>> the warning in these cases. >>> >>>> 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, and if so, what's the >>>> thread's backtrace like. >>> >>> I added CHECK to that call to GetThreadContext. It never produced a >>> warning in all my testing, and it looks like we do succeed to get the >>> registers. At least the registers of 2 such threads show different >>> contents, and the EIP value is consistent with what "info threads" >>> displays. >> >> It isn't clear to me whether you're saying that you saw the >> SuspendThread failure trigger in all your new testing, so that >> we'd know for sure whether GetThreadContext suceeds in that case, >> or whether it might have been that you just were "lucky" enough >> to not trigger the SuspendThread failure issue. > > The former. > >> Does your patch fix the test case in PR14018, without producing >> a CHECK warning from the new CHECK in GetThreadContext you've >> added? > > Yes. Ah, excellent! Thank you. Please remember adding the PR number to the ChangeLog entry then. >> Why bother calling SetThreadContext at all if we just killed >> the process? > > See my other mail and Joel's response. Not sure what you mean. TerminateProcess is asynchronous, and we need to resume the inferior and collect the debug events until we see the process terminate. But, my question is why would we write the thread's registers at all if we just told it to die? Seems to be we could just skip calling SetThreadContext instead of calling it but ignoring the result. > >>> Finally, here's the full patch. I hope this research answered all the >>> questions, and we can now get the patch in. >> >> I'm not sure it did, but in any case the patch looks good to me. > > If that's an approval, I will happily commit the changes. It's an approval from my end. >> Sounds like GDBserver might have this problem too. > > If there's an easy way to verify that, without having 2 systems > talking via some communications line, please tell how, and I will try > that. Sure, you can run gdbserver and gdb on the same machine, and connect with tcp. Just: $ gdbserver :9999 myprogram.exe in one terminal, and: $ gdb myprogram.exe -ex "tar rem :9999" -ex "b main" -ex "c" in another. -- Pedro Alves