Re: [PATCH] Windows gdb: Avoid hang second attach/run

[Pedro Alves <pedro@palves.net>]

On 2026-05-05 15:05, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <pedro@palves.net> writes:
> 
> Pedro> windows_nat_target::attach and windows_nat_target::create_inferior
> Pedro> both hang in this situation, because they call into do_synchronously,
> Pedro> which hangs because the 'process_thread' thread is blocked in
> Pedro> WaitForDebugEvent.
> 
> Do we need something similar for gdbserver?

We don't, because gdbserver does not have the do_synchronously machinery for async, and, also,
because core gdbserver rejects the attach earlier:

  if (startswith (own_buf, "vAttach;"))
    {
      if ((!extended_protocol || !cs.multi_process) && target_running ())
	{
	  fprintf (stderr, "Already debugging a process\n");
	  write_enn (own_buf);
	  return;
	}

We get:

 attach 22600
 Attaching to Remote target
 Attaching to Remote target failed: 01
 (gdb) FAIL: gdb.base/attach.exp: do_attach_failure_tests: fail to attach again

BTW, I'm been thinking that the slow piecemeal sharing of code between gdb and gdbserver's Windows
backends is a lost cause by now.  The backends started diverging a lot with the async support,
and more so now with the non-stop support.  They used to be very similar before.

I've been thinking that it'll be easier to completely dump gdbserver/win32-low.c, make
gdbserver build gdb/windows-nat.c (and friends), start with some #ifdefs, and then work on
eliminating the #ifdefs incrementally with some abstractions and/or normalizing gdb and
gdbserver core<=>backend interfaces more.

> 
> Pedro> Until the Windows backend is taught to debug multiple processes, which
> Pedro> will probably require having one process_thread thread per inferior,
> Pedro> detect the situation and error out before GDB hangs.
> 
> Yeah.  I've never understood why MS did things this way instead of the
> seemingly obvious approach of having debug events integrated into
> WaitForMultipleObjects.
> 
> Pedro> There are still other failures not addressed by this patch.
> 
> FWIW the internal AdaCore automated testing shows a number of failures
> after a merge on 20260427.  I guess when I did my testing I happened to
> pick the one particular OS instance that had no problems :(
Ouch, I was indeed surprised that you saw no problems.  :-/

(To be clear, the failures I mean above are pre-existing failures in gdb.base/attach.exp.)

Pedro Alves