From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6000 invoked by alias); 8 Apr 2014 15:17:46 -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 5984 invoked by uid 89); 8 Apr 2014 15:17:45 -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: mtaout20.012.net.il Received: from mtaout20.012.net.il (HELO mtaout20.012.net.il) (80.179.55.166) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 08 Apr 2014 15:17:43 +0000 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0N3P00I00WYF2300@a-mtaout20.012.net.il> for gdb-patches@sourceware.org; Tue, 08 Apr 2014 18:17:27 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N3P00HTXX52YE10@a-mtaout20.012.net.il>; Tue, 08 Apr 2014 18:17:27 +0300 (IDT) Date: Tue, 08 Apr 2014 15:17:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH] Fix "PC register is not available" issue In-reply-to: <20140408042331.GF4250@adacore.com> To: Joel Brobecker Cc: palves@redhat.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83d2gr7sw0.fsf@gnu.org> References: <834n2kztfw.fsf@gnu.org> <53358C37.9050907@redhat.com> <83a9cafcpz.fsf@gnu.org> <5335B619.6040605@redhat.com> <8361myfa6l.fsf@gnu.org> <83ioqucrkw.fsf@gnu.org> <5342DBBC.4090500@redhat.com> <83lhvh6lqi.fsf@gnu.org> <20140407213913.GE4250@adacore.com> <83ha647d6d.fsf@gnu.org> <20140408042331.GF4250@adacore.com> X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00099.txt.bz2 > Date: Mon, 7 Apr 2014 21:23:31 -0700 > From: Joel Brobecker > Cc: palves@redhat.com, gdb-patches@sourceware.org > > > Sorry, I don't understand: remote.c is not specific to Windows, so it > > cannot include any Windows-specific calls like SuspendThread. > > I think the easiest is probably for you to take a look at the code > in gdb/gdbserver/win32-low.c. I altready did, but you seemed to say that code will not be used, which confused me. > This file actually also has a routine > called thread_rec, and generally speaking, the code in gdb/*-nat.c > and the corresponding gdb/gdbserver/*-low.c can (and probably should) > be very similar - at least until we can factorize that code and reuse > the gdbserver code in GDB. Yes, I know. I've read the code. > The reason I was mentioning remote.c is because, when you use GDBserver, > GDBserver does all the inferior control for GDB. It's like a mini > debugger, except that it does not have a user interface, only a serial > interface that GDB can used to communicate with it and send it orders > such as read or write memory, next/step operations, continue, kill, > etc. So, even if you are using a Windows native debugger, as soon as > you type the "target remote [...]" command, the windows-nat target > gets swapped out in favor of the "remote" target, which then delegates > the inferior control to the agent (gdbserver). The code that does that > delegation is in remote.c. I know that, too. What I don't understand is how all this is relevant to the issue at hand, which is why the same system calls in win32-low.c as we have in windows-nat.c don't trigger similar warning messages. > So, to try to reproduce with GDBserver, you'd have to do the following. > In one terminal, start your program with gdbserver. For instance: > > % gdbserver --debug :4567 YOUR_PROGRAM Why do I need --debug? The warnings in question are displayed by OUTMSG, which AFAIU does not need --debug to print its messages. > It'll write a message saying that the program has been started, > and that it's now waiting for a connection on port 4567. The --debug > switch is not normally necessary, but allows us to turn warnings on, > which then allows us to determine whether or not we reproduced the > problem in GDB. > > Next, start GDB in a second terminal, and connect to it via: > > % gdb YOUR_PROGRAM > (gdb) target remote :4567 > > The "target remote [...]" command replaces the "run" command. > >From there, everything else should be the same as the reproducer > you have for the case where GDBserver isn't involved. I already did all that, per Pedro's instructions here: https://sourceware.org/ml/gdb-patches/2014-03/msg00668.html > And instead of seeing the warning in the GDB console, you would > see it in the terminal where gdbserver was started. But that's it: I see no warnings when I run GDBserver like that.