From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7861 invoked by alias); 31 Mar 2014 15:31:42 -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 7842 invoked by uid 89); 31 Mar 2014 15:31:41 -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,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout22.012.net.il Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 31 Mar 2014 15:31:40 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0N3B004004E89600@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Mon, 31 Mar 2014 18:31:37 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N3B003OL4GPFFA0@a-mtaout22.012.net.il>; Mon, 31 Mar 2014 18:31:37 +0300 (IDT) Date: Mon, 31 Mar 2014 15:31:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH] Fix "PC register is not available" issue In-reply-to: <8361myfa6l.fsf@gnu.org> To: palves@redhat.com Cc: brobecker@adacore.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83ioqucrkw.fsf@gnu.org> 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> <5335B619.6040605@redhat.com> <8361myfa6l.fsf@gnu.org> X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00696.txt.bz2 > Date: Fri, 28 Mar 2014 21:30:10 +0300 > From: Eli Zaretskii > Cc: brobecker@adacore.com, gdb-patches@sourceware.org > > > Date: Fri, 28 Mar 2014 17:49:13 +0000 > > From: Pedro Alves > > CC: brobecker@adacore.com, gdb-patches@sourceware.org > > > > >> 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. > > If you say so, I don't know enough about this stuff. Actually, upon second thought: we continue the inferior after TerminateProcess call to let it be killed, right? If so, shouldn't we continue it with the right context? > > >> 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. > > OK, will try that. Funnily enough, I cannot get GDBserver to emit similar warnings in the same situation. I don't understand the reasons for that, since the code is very similar, and with a single exception, we do check the return values of calls to GetThreadContext, SetThreadContext, and SuspendThread in GDBserver. But the fact remains that no warnings about these threads are ever seen when debugging remotely. I do see the extra threads under GDBserver as well. Does anyone have any further ideas?