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

[Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org>]

On Sat, May 10, 2008 at 08:31:02AM -0700, Joel Brobecker wrote:
>Hi Chris,
>
>> I think the way this is handled in linux is by resetting the controlling
>> process group of the terminal to the pid of the inferior.  On thinking
>> about this more, I think it probably makes more sense to bracket the
>> call with:
>> 
>>   SetConsoleCtrlHandler (NULL, TRUE);
>>   retval = get_win32_debug_event (pid, ourstatus);
>>   SetConsoleCtrlHandler (NULL, FALSE);
>> 
>> That's almost equivalent to what linux does with process groups I think.
>> 
>> Does the above work in your scenario, Joel?  If so, I think this is
>> safe to check in.
>
>I think it does work. All my experiments at resuming the inferior after
>having interrupted it with C-c have been succesful.
>
>The only problem is that once in a while GDB still receives the SIGINT.
>This time, it doesn't cause the debugger to QUIT during the resume after
>handling the new-thread event like it used to, so we properly report the
>SIGINT event to the user:
>
>    (gdb) cont
>    Continuing.
>    I = 10
>    I = 11
>    I = 12
>    [New thread 2348.0x1550]  <<<---  pressed C-c
>    
>    Program received signal SIGINT, Interrupt.
>    [Switching to thread 2348.0x1550]
>    0x7c87534d in KERNEL32!GetConsoleCharType (Quit (expect signal SIGINT when the program is resumed)
>
>However, because the SIGINT handler was called, we still get the unexpected
>"Quit (expect signal SIGINT when the program is resumed" message in
>the middle of printing the current frame. As I said earlier, it doesn't
>prevent the next resume to work properly. It's a little misleading but
>I think this is already a good improvement, so I suggest we go with your
>suggestion.

I think there is obviously a race here.  Possibly just calling
SetConsoleCtrlHandler (NULL, TRUE) before calling CreateProcess is all
that's required to handle it but looking at inflow.c it seems like
the process group handling that gdb is expecting is more complicated
than a turn-it-all-off or turn-it-all-on.

I assume that you're using a mingw version of cygwin so I don't know the
setting for the job_control variable.  If it is off, it seems like it
should be doing the right thing already.  If it's on then I could see
that as being a problem.

Or, maybe it would make sense to use job_control as it was intended.  We
could kludge up a tcsetpgrp for windows which messed with CTRL-C
handling for gdb based on whether it was being called with the gdb
process group or the inferior process group.  This is under the
assumption that the race you're seeing is already being handled by gdb
but is being bypassed because the windows platform doesn't have enough
capabilities to do the right thing.

cgf