Re: [PATCH] [RFC] Move SetConsoleCtrlHandler calls to async thread

[Tom Tromey <tromey@adacore.com>]

>>>>> "Hannes" == Hannes Domani via Gdb-patches <gdb-patches@sourceware.org> writes:

Hannes> Ctrl-C and Ctrl-Break don't work any more since the async commit, so I've tried
Hannes> to move the SetConsoleCtrlHandler calls.
Hannes> Now Ctrl-C seems to work, but Ctrl-Break completely stop both gdb and the
Hannes> inferior (if new-console is disabled).

Hannes> I'm not sure what's the proper fix is here, please advise.

In my normal environment (ssh to a Windows machine), none of this has
ever worked at all.  I don't know why, something to do with ssh and/or
cygwin.

Anyway, I managed to test C-c by using remmina (RDP client) and then
running gdb in the console provided there.  I used conemu which I gather
opened some kind of Cygwin shell.

According to winver this machine is "Windows Server 2016".

I tried a few versions:

1. AdaCore internal gdb from before the target async patches.  (AdaCore
   has some local changes, but nothing relevant to this problem.)

2. AdaCore gdb corresponding to git master, plus your other recent
   windows-nat patches.

3. #2 plus your C-c patch.

When I use "run" in gdb, control-c and control-break worked fine with 1
and 2.  (FWIW I used the on-screen keyboard to send control-break, I
don't know any other way to do it.)

When I use "attach", neither 1 nor 2 work at all -- but your patch does,
but only for C-c.  C-break just makes gdb exit.

Now, TBH, I find all of this surprising, because on seeing your patch, I
agree that the target async work should cause a problem here.  And, I
don't understand why your patch fixes the "attach" behavior.

With your patch installed, C-c still works, but C-break does not.  I
don't understand why this happens.  My understanding is that
SetConsoleCtrlHandler intercepts C-break as well, and the body of that
callback hasn't changed.

One other thing I don't understand is that C-c doesn't cause gdb to exit
when it is waiting at the prompt.  Instead I get this quit message:

    throw_quit ("Quit (expect signal SIGINT when the program is resumed)");

Like, if this happens, do we really need ctrl_c_handler for the C-c case
at all?  (Maybe we do need the handler because windows-nat doesn't use
set_sigint_trap.)  And should gdb default to handling ctrl-break as
well?  Like, I wonder if there's a race between something like the call
to signal in child_terminal_inferior and installing the C-c handler.

The comment in windows-nat says:

		 [...]  There are two
		 possible situations:

		   - The debugger and the program do not share the console, in
		     which case the Ctrl-c event only reached the debugger.
		     In that case, the ctrl_c handler will take care of
		     interrupting the inferior.  Note that this case is
		     working starting with Windows XP.  For Windows 2000,
		     Ctrl-C should be pressed in the inferior console.

Maybe the 'attach' issue is a known problem?

Anyway.  I've learned that there's a lot in this area I don't
understand.  I think the first thing to do is understand why we get
different results.  I wonder what I could change here to reproduce the
problem.  Maybe I shouldn't be using conemu but instead something else?

Tom