From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22670 invoked by alias); 7 Apr 2014 16:58:16 -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 22656 invoked by uid 89); 7 Apr 2014 16:58:15 -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; Mon, 07 Apr 2014 16:58:15 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 261661160DE; Mon, 7 Apr 2014 12:58:13 -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 piO2CX00jvvz; Mon, 7 Apr 2014 12:58:13 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id DF47F1160DD; Mon, 7 Apr 2014 12:58:12 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 131D9E0BF1; Mon, 7 Apr 2014 09:58:14 -0700 (PDT) Date: Mon, 07 Apr 2014 16:58: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: <20140407165814.GD4250@adacore.com> References: <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> <83ioqucrkw.fsf@gnu.org> <83ha6887re.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83ha6887re.fsf@gnu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-04/txt/msg00080.txt.bz2 > Ping! If there are no further suggestions, I'd like to commit the > changes posted in this thread. FWIW, I think you can go ahead. Your patches seem to be an improvement, and I don't see how they could make things worse should we want to work on another way to implement this part of the code again. > > > Date: Mon, 31 Mar 2014 18:31:43 +0300 > > From: Eli Zaretskii > > Cc: brobecker@adacore.com, gdb-patches@sourceware.org > > > > > 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? Sure, but what context would that be? > > > > > > >> 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? -- Joel