-
- /* Ignore CTRL+C signals while waiting for a debug event.
- FIXME: brobecker/2008-05-20: When the user presses CTRL+C while
- the inferior is running, both the inferior and GDB receive the
- associated signal. If the inferior receives the signal first
- and the delay until GDB receives that signal is sufficiently long,
- GDB can sometimes receive the SIGINT after we have unblocked
- the CTRL+C handler. This would lead to the debugger to stop
- prematurely while handling the new-thread event that comes
- with the handling of the SIGINT inside the inferior, and then
- stop again immediately when the user tries to resume the execution
- in the inferior. This is a classic race, and it would be nice
- to find a better solution to that problem. But in the meantime,
- the current approach already greatly mitigate this issue. */
- SetConsoleCtrlHandler (NULL, TRUE);
- retval = get_windows_debug_event (pid, ourstatus);
- SetConsoleCtrlHandler (NULL, FALSE);
+
+ /* If the user presses Ctrl-c while the debugger is waiting
+ for an event, he expects the debugger to interrupt his program
+ and to get the prompt back. 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.
+
+ - The debugger and the program share the same console, in which
+ case both debugger and inferior will receive the Ctrl-c event.
+ In that case the ctrl_c handler will ignore the event, as the
+ Ctrl-c event generated inside the inferior will trigger the
+ expected debug event.
+
+ FIXME: brobecker/2008-05-20: If the inferior receives the
+ signal first and the delay until GDB receives that signal
+ is sufficiently long, GDB can sometimes receive the SIGINT
+ after we have unblocked the CTRL+C handler. This would
+ lead to the debugger stopping prematurely while handling
+ the new-thread event that comes with the handling of the SIGINT
+ inside the inferior, and then stop again immediately when
+ the user tries to resume the execution in the inferior.
+ This is a classic race that we should try to fix one day. */
+ SetConsoleCtrlHandler (&ctrl_c_handler, TRUE);
+ retval = get_windows_debug_event (ops, pid, ourstatus);
+ SetConsoleCtrlHandler (&ctrl_c_handler, FALSE);