On 10/16/2015 05:22 PM, Joel Brobecker wrote:
>> I'm trying to build a Windows gdb to see this in
>> action.  Many thanks for the detailed analysis!
> 
> Thanks Pedro. Let me know if I can help, I don't mind doing the
> leg-work! It's just that I needed a bit of guidance because I don't
> have the whole picture on how the mainloop is supposed to work,
> particulary with the async-vs-non-async, all-stop-vs-non-stop,
> etc.
> 

I had forgotten how building on Cygwin takes ages! :-P

So my main gripe with the patch is this:

@@ -2821,6 +2821,15 @@ attach_command (char *args, int from_tty)
 	mark_infrun_async_event_handler ();
       return;
     }
+  else
+    {
+      /* We don't expect any additional attach event from the target.
+	 So make sure that the infrun_async_event_handler is disabled.
+	 Otherwise, the main event loop might believe that we have
+	 inferior events ready, causing us to wait for those event
+	 that will never come, since our inferior is now stopped.  */
+      infrun_async (0);
+    }

If debugging more than one inferior (granted, Windows doesn't
support this, but, alas), this prevents gdb from reacting to pending events
for threads of the other inferior.

How about we make do_initial_windows_stuff call windows_wait/windows_resume
directly, like we did for gdbserver here:

  https://sourceware.org/ml/gdb-patches/2013-12/msg00371.html

As mentioned in that thread, I've wanted to do this before
in order to get rid of stop_after_trap.

The patch below seems to work for me.

Thanks,
Pedro Alves