[RFC] control-c handling on Windows...

[Joel Brobecker <brobecker@adacore.com>]

[-- Attachment #1: Type: text/plain, Size: 2308 bytes --]

Hello,

We noticed the following anomaly when trying to interrupt the inferior
with a control-c event:

(gdb) run
Starting program: C:\[...]/always.exe
[New thread 6772.0xadc]
Hello world: 1
Hello world: 2
[New thread 6772.0x13fc]
[Switching to thread 6772.0x13fc]
Quit (expect signal SIGINT when the program is resumed)
(gdb)

The debugger stopped but doesn't show the usual "Program received
SIGINT [...]" message. It almost looks like the debugger stopped
because of the new thread.

Also, the "Quit (expect signal SIGINT when the program is resumed)"
message is indeed right. When I do a "continue", I immediately get
the SIGINT:

    (gdb) c
    Continuing.
    Hello world: 3
    Program received signal SIGINT, Interrupt.
    0x7c87534d in KERNEL32!GetConsoleCharType ()
       from C:\WINDOWS\system32\kernel32.dll
    (gdb)

In fact, what happened was that GDB received a SIGINT event,
and as such set the quit_flag. At the same time, the inferior
received the control-c event as well, and therefore created
a new thread to handle it. That new thread generated an event
intercepted by GDB; after GDB updated its thread list, it tried
to resume the execution. However, there is a QUIT at the very
beginning of resume which, because of quit_flag being set,
aborted the resume action. This is why GDB stopped the first
time instead of resuming until we get the control-c exception
event.

I think this is happening because of a change that was made a year
ago which adds a call to target_terminal_ours at the beginning of
win32_wait().  As a result, the SIGINT handler gets reactivated while
the inferior is running.  This change was made because TUI apparently
does some output while the terminal process group is set to the inferior
process.

For now, the attached patch seems to work around the issue, but
I'm a little suspicious of grabing the terminal while we're waiting
for an event. (I will add more comment in my patch when the situation
is a little clarified).

Opinions? For reference, the target_terminal_ours patch is:

        * win32-nat.c (win32_wait): Reset terminal pgrp to GDB.
        (do_initial_win32_stuff): Call terminal_init_inferior_with_pgrp
        instead of target_terminal_init since inferior_ptid isn't set yet.

and it was checked in on Feb 12, 2007.

Thanks,
-- 
Joel

[-- Attachment #2: win32-nat.c.diff --]
[-- Type: text/plain, Size: 539 bytes --]

Index: win32-nat.c
===================================================================
--- win32-nat.c	(revision 130731)
+++ win32-nat.c	(working copy)
@@ -1467,7 +1467,13 @@ win32_wait (ptid_t ptid, struct target_w
 
   while (1)
     {
-      int retval = get_win32_debug_event (pid, ourstatus);
+      int retval;
+      void (*ofunc) (int);
+
+      ofunc = signal (SIGINT, SIG_IGN);
+      retval = get_win32_debug_event (pid, ourstatus);
+      signal (SIGINT, ofunc);
+
       if (retval)
 	return pid_to_ptid (retval);
       else