Re: [PATCH 1/7] Merge async and sync code paths some more

[Joel Brobecker <brobecker at adacore dot com>]

> 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.

Ah, yes indeed. And besides, the patch is not Windows-specific
either, so presumably could negatively affect another target
that does support multi-inferior debugging.

> 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.

Of course! Why take the roundabout way when you can take the direct
route? I don't see a reason in this case, and it completely avoids
the issue of the async even handler. And it looks like a nice
simplification to boot, at least to me.

Patch looks good, and I tested it against AdaCore's testsuite, showing
that it fixes the "attach" regressions without introducing any new
failure.

Slightly unrelated to your patch, now, but would you mind sharing
your thoughts on:

> I couldn't figure out why we needed both infrun_async and
> mark_infrun_async_event_handler, and in particular, I didn't
> see the need for the infrun_is_async != enable guard.
> So, this patch just makes infrun_async always call the
> relevant {mark,clear}_infrun_async_event_handler routine.
>
> If you agree that's the right thing to do, I propose we delete
> {mark,clear}_infrun_async_event_handler, or replace them by
> the associated infrun_async routine. Although, from someone
> not very familiar with all this async stuff, the function
> names {mark,clear}_infrun_async_event_handler speak a little
> more to me. On the other hand, I like infrun_async because of
> the debug trace. So we could also eliminate infrun_async and
> move the debug trace into {mark,clear}_infrun_async_event_handler.
> We'd have to make clear_infrun_async_event_handler non-static.

If there is an improvement to be had, be it just adding more comments,
I can take care of that.

Thanks a lot!
-- 
Joel