tree 4c4854b15c26ab4222ba06b94e8fd5a2310385e5
parent 5739a1b98daf68fd81fed9af9667a2b9671928f9
author Pedro Alves <pedro@palves.net> 1713376621 +0100
committer Pedro Alves <pedro@palves.net> 1713376621 +0100

gdb/Windows: Fix detach while running

While testing a WIP Cygwin GDB that supports non-stop, I noticed that
gdb.threads/attach-non-stop.exp exposes that this:

 (gdb) attach PID&
 ...
 (gdb) detach

... hangs.

And it turns out that it hangs in all-stop as well.  This commits
fixes that.

After "attach &", the target is set running, we've called
ContinueDebugEvent and the process_thread thread is waiting for
WaitForDebugEvent events.  It is the equivalent of "attach; c&".

In windows_nat_target::detach, the first thing we do is
unconditionally call windows_continue (for ContinueDebugEvent), which
blocks in do_synchronously, until the process_thread sees an event out
of WaitForDebugEvent.  Unless the inferior happens to run into a
breakpoint, etc., then this hangs indefinitely.

If we've already called ContinueDebugEvent earlier, then we shouldn't
be calling it again in ::detach.

Still in windows_nat_target::detach, we have an interesting issue that
ends up being the bulk of the patch -- only the process_thread thread
can call DebugActiveProcessStop, but if it is blocked in
WaitForDebugEvent, we need to somehow force it to break out of it.
The only way to do that, is to force the inferior to do something that
causes WaitForDebugEvent to return some event.

This patch uses CreateRemoteThread to do it, which results in
WaitForDebugEvent reporting CREATE_THREAD_DEBUG_EVENT.  We then
terminate the injected thread before it has a chance to run any
userspace code.

Note that Win32 functions like DebugBreakProcess and
GenerateConsoleCtrlEvent would also inject a new thread in the
inferior.  I first used DebugBreakProcess, but that is actually more
complicated to use, because we'd have to be sure to consume the
breakpoint event before detaching, otherwise the inferior would likely
die due a breakpoint exception being raised with no debugger around to
intercept it.

See the new break_out_process_thread method.

So the fix has two parts:

 - Keep track of whether we've called ContinueDebugEvent and the
   process_thread thread is waiting for events, or whether
   WaitForDebugEvent already returned an event.

 - In windows_nat_target::detach, if the process_thread thread is
   waiting for events, unblock out of its WaitForDebugEvent, before
   proceeding with the actual detach.

New test included.  Passes cleanly on GNU/Linux native and gdbserver,
and also passes cleanly on Cygwin and MinGW, with the fix.  Before the
fix, it would hang and fail with a timeout.

Tested-By: Hannes Domani <ssbssa@yahoo.de>
Reviewed-By: Tom Tromey <tom@tromey.com>
Change-Id: Ifb91c58c08af1a9bcbafecedc93dfce001040905