Re: [PATCH] Fix "PC register is not available" issue

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 7 Apr 2014 21:23:31 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> 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.