Fix control-c handling on Windows
authorTom Tromey <tromey@adacore.com>
Mon, 5 Dec 2022 17:56:23 +0000 (10:56 -0700)
committerTom Tromey <tromey@adacore.com>
Tue, 13 Dec 2022 19:51:53 +0000 (12:51 -0700)
commitc88afe9cf5d7fb0bd878acb930d79aafcf182505
treeaa074a83270492bc86695706e82b322d67ab34b8
parentc1dc47f53cccf633f3079db25a5b41adaee940a8
Fix control-c handling on Windows

As Hannes pointed out, the Windows target-async patches broke C-c
handling there.  Looking into this, I found a few oddities, fixed
here.

First, windows_nat_target::interrupt calls GenerateConsoleCtrlEvent.
I think this event can be ignored by the inferior, so it's not a great
way to interrupt.  Instead, using DebugBreakProcess (or a more
complicated thing for Wow64) seems better.

Second, windows_nat_target did not implement the pass_ctrlc method.
Implementing this lets us remove the special code to call
SetConsoleCtrlHandler and instead integrate into gdb's approach to C-c
handling.  I believe that this should also fix the race that's
described in the comment that's being removed.

Initially, I thought a simpler version of this patch would work.
However, I think what happens is that some other library (I'm not sure
what) calls SetConsoleCtrlHandler while gdb is running, and this
intercepts and handles C-c -- so that the gdb SIGINT handler is not
called.  C-break continues to work, presumably because whatever
handler is installed ignores it.

This patch works around this issue by ensuring that the gdb handler
always comes first.
gdb/event-top.c
gdb/extension.c
gdb/inferior.h
gdb/inflow.c
gdb/mingw-hdep.c
gdb/posix-hdep.c
gdb/windows-nat.c