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

[Joel Brobecker <brobecker@adacore.com>]

> 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. 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.

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.

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

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.

And instead of seeing the warning in the GDB console, you would
see it in the terminal where gdbserver was started. The idea for
solving the issue on the gdbserver side would be to apply the very
same sort of change you applied to windows-nat, but to win32-low,
essentially keeping the implementations in sync.

-- 
Joel