This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] control-c handling on Windows...
On Sat, May 10, 2008 at 11:00:10AM -0700, Joel Brobecker wrote:
>> If only I understood signals and terminals better, I would try to
>> understand the reason why GDB still gets the SIGINT despite all our
>> efforts. But, right now, I'm a little in the dark :(. I know that
>> Nicolas Roche, one of the engineers at AdaCore, has spent quite
>> a bit of time studying this sort of issues, so I'll see if I can
>> nudge him a little out of his busy schedule to share some of the ideas
>> he had.
>
>I spoke with Nico a little. He is pretty certain, based on what he read
>of the Windows documentation, that we cannot avoid having GDB receive
>the SIGINT. Apparently, the console is responsible for sending those
>signals, and its behavior cannot be changed.
>
>I wonder if there might be some sort of timing issue that causes
>the signal to sometimes be delivered after we stopped ignoring control
>events. In other words, some of the time, we receive the signal
>reasonably close to when we receive the debug event for the new thread,
>and so it gets ignored. But some other time, we receive the signal
>sufficiently after we got the debug event that we already got out of
>get_win32_debug_event and restored the regular SIGINT handler...
>That would explain why we're seeing the QUIT message.
i.e., it's a classic race.
>So the problem becomes when to handle the signal and when to ignore it.
>I'll keep thinking about it for a while, but I haven't found a solution
>yet.
>
>On a side note, utils.c:quit is:
>
> void
> quit (void)
> {
> #ifdef __MSDOS__
> /* No steenking SIGINT will ever be coming our way when the
> program is resumed. Don't lie. */
> fatal ("Quit");
> #else
> if (job_control
> /* If there is no terminal switching for this target, then we can't
> possibly get screwed by the lack of job control. */
> || current_target.to_terminal_ours == NULL)
> fatal ("Quit");
> else
> fatal ("Quit (expect signal SIGINT when the program is resumed)");
> #endif
> }
>
>Not sure when __MSDOS__ is defined, but perhaps we should extend
>that case to mingw & cygwin as well? At least we wouldn't get the
>"expect signal SIGINT when the program is resumed" part which
>I don't think can happen on Windows anymore.
I'm still assuming that you're talking about mingw here since Cygwin should
have different behavior. For instance, it implements tcsetpgrp.
cgf