Re: [PATCHv8 4/6] gdb/remote: avoid SIGINT after calling remote_target::stop

[Pedro Alves <pedro@palves.net>]

(I'll go back to reviewing the other patches in the series, but I wanted to
reply to this one immediately.)

I think this patch is just incorrect, design wise, and we should not merge it.

There is absolutely no connection between any selected thread in GDB to the
thread that eventually reports the SIGINT, because the \x03 packet carries no
thread context.  So GDB could ask for target_stop({pid=123, lwpid=999}), and
if we end up sending \x03, the thread that gets the SIGINT could be
say, {pid=123, lwpid=123}, or even {pid=666, lwpid=666}.

On Windows, both GenerateConsoleCtrlEvent and DebugBreakProcess (the functions
used by win32_process_target::request_interrupt()) inject a new thread
in the inferior and has _thread_ thread report the event.  So the thread that
reports the interrupt is completely unknown to GDB at the time the \x03 is sent.

Also, there's even no guarantee that you'll get a SIGINT instead of some
other signal.  On Windows, DebugBreakProcess results in SIGTRAP.

We should just not assume that target_stop with an all-stop backend is able
to stop a specific thread.

Pedro Alves