Re: [PATCH v2] gdb/Windows: Fix detach while running

[Pedro Alves <pedro@palves.net>]

On 2024-04-15 18:02, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <pedro@palves.net> writes:
> 
> Pedro> Still in windows_nat_target::detach, we have an interesting issue that
> Pedro> ends up being the bulk of the patch -- only the process_thread thread
> Pedro> can call DebugActiveProcessStop, but if it is blocked in
> Pedro> WaitForDebugEvent, we need to somehow force it to break out of it.
> Pedro> The only way to do that, is to force the inferior to do something that
> Pedro> causes WaitForDebugEvent to return some event.
> 
> I generally like the Windows debug API but I can't really understand why
> they didn't integrate WaitForDebugEvent with WaitForMultipleObjects --
> it seems like such an obvious thing to do and it would have saved so
> many headaches.
> 
> I didn't read the patch in too much detail, but I did look over it and I
> read through the explanation.  It all makes sense to me.
> 
> I was wondering if something similar is needed for gdbserver?
> I assume not though.

It doesn't for two reasons:

#1 - gdbserver doesn't wait for Windows debug events with a separate thread.

#2 - in order to detach while the inferior is running with a remote target, we must
     be using the non-stop variant of the RSP (so we can send a packet other than
     \03 while the target is running), which the Windows gdbserver port does not support
     (and would need #1).

ATM, I can only focus mostly on native non-stop, other than making sure gdbserver
doesn't break.  But after the non-stop work, the gdb and gdbserver backends end up a
bit more similar in some areas, hopefully we'll end up being able to share more code
later on.

> 
> Reviewed-By: Tom Tromey <tom@tromey.com>
> 

Thanks.  I've added this and merged the patch.