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

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

[Joel Brobecker]

[-- 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

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

[Christopher Faylor]

On Wed, May 07, 2008 at 01:56:11PM -0700, Joel Brobecker wrote:
>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.

Thanks for the analysis.  I've talked to Corinna about this since she
was responsible for the original patch in question.  I think her patch
still makes sense so I guess your change is required although I can't
shake the feeling that there is some CreateProcess setting that we're
missing to deal with this behavior.

But, if your patch fixes the problem I'm ok with checking it in.

cgf

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

[Joel Brobecker]

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

Hi Chris,

> Thanks for the analysis.  I've talked to Corinna about this since she
> was responsible for the original patch in question.  I think her patch
> still makes sense so I guess your change is required although I can't
> shake the feeling that there is some CreateProcess setting that we're
> missing to deal with this behavior.

I had a second look at the issue that Corinna was facing. I am not
entirely sure that I'm seeing the exact same problem, but the symptoms
are the same (gdbtui's process goes into background).

As far as I can tell, here is the sequence of events that lead to
the problem:

  1. win32_create_inferior creates the process, and then calls
     do_initial_win32_stuff.
  2. do_initial_win32_stuff then gives the terminal to the inferior,
     and then does a wait_for_inferior () until we get the expected
     SIGTRAP.
  3. wait_for_inferior leads us to calling win32_wait which calls
     which in turn calls get_win32_debug_event.
  4. As expected, we get our CREATE_PROCESS_DEBUG_EVENT. As a result,
     we add this new pid to the list of threads calling
     win32_add_thread.
  5. win32_add_thread calls add_thread as well, which calls
     add_thread_with_info. This is where things get interesting:

          if (print_thread_events)
            printf_unfiltered (_("[New %s]\n"), target_pid_to_str (ptid));

When I remove this printf_unfiltered, the startup phase completes fine.
I was going to propose that we therefore remove the target_terminal_ours
out of win32_wait and bracket the call to add_thread with
target_terminal_ours/target_terminal_inferior. Things seemed to work
relatively fine, except that I occasionally got the wrong behavior
when pressing C-c. Also, the new suggestion would not take care of
the multiple DEBUG traces that we can get GDB to print.

As far as I can tell, it almost looks like the SIGINT is buffered
until we switch the terminal to the debugger.  Using printfs,
the sequence I see is: we see the new thread, we switch the terminal
to ours to print the new thread event, we receive the SIGINT...
I just don't understand.

> But, if your patch fixes the problem I'm ok with checking it in.

I think that this is probably the easiest to solve all problems.
Here is the same patch, but with a comment explaining why we temporarily
ignore SIGINT...

2008-05-10  Joel Brobecker  <brobecker@adacore.com>

        * win32-nat.c (win32_wait): Ignore SIGINT while waiting for
        a debug event.

I thought you might have some comments/suggestions on the comment,
so I'll wait for your OK before checking it in.

Thanks,
-- 
Joel

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

Index: win32-nat.c
===================================================================
--- win32-nat.c	(revision 130731)
+++ win32-nat.c	(working copy)
@@ -1467,7 +1467,20 @@ win32_wait (ptid_t ptid, struct target_w
 
   while (1)
     {
-      int retval = get_win32_debug_event (pid, ourstatus);
+      int retval;
+      void (*ofunc) (int);
+
+      /* For some reason, even when the terminal is owned by the inferior,
+         pressing control-c in the debugger window sometimes leads to
+         the debugger getting the associated SIGINT, which is unexpected.
+         In fact, both the inferior and the debugger get this signal.
+         To avoid getting this signal in the debugger, we temporarily
+         ignore SIGINT while waiting for debug events.  However, this
+         might be a symptom of a problem in our terminal settings.  */
+      ofunc = signal (SIGINT, SIG_IGN);
+      retval = get_win32_debug_event (pid, ourstatus);
+      signal (SIGINT, ofunc);
+
       if (retval)
 	return pid_to_ptid (retval);
       else

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

[Christopher Faylor]

On Fri, May 09, 2008 at 06:33:37PM -0700, Joel Brobecker wrote:
>> But, if your patch fixes the problem I'm ok with checking it in.
>
>I think that this is probably the easiest to solve all problems.
>Here is the same patch, but with a comment explaining why we temporarily
>ignore SIGINT...
>
>2008-05-10  Joel Brobecker  <brobecker@adacore.com>
>
>        * win32-nat.c (win32_wait): Ignore SIGINT while waiting for
>        a debug event.
>
>I thought you might have some comments/suggestions on the comment,
>so I'll wait for your OK before checking it in.

I don't think the comment is right.  I think it is expected behavior
that both gdb and the inferior should see the CTRL-C since they are both
associated with the same console.  I don't know this for sure because
Windows concept of process groups are sort of a mystery to me.

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.

cgf

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

[Joel Brobecker]

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.

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.

-- 
Joel

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

[Christopher Faylor]

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

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

[Joel Brobecker]

> 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.

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.

-- 
Joel

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

[Eli Zaretskii]

> Date: Sat, 10 May 2008 11:00:10 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> 
>     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

It's defined in the DJGPP build of GDB.  This bogus "expect SIGINT"
message was bugging me for years, until I #ifdef'ed it away.

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

[Christopher Faylor]

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

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

[Joel Brobecker]

> >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.

Yes, and I'm still not sure how to solve it completely :-(. I double-checked
the cygwin case inside a cygwin window, and things seem to be pretty solid
as soon as the SetConsoleCtrlHandler wrapper is installed. Not sure whether
it's a coincidence or whether it's expected that I wouldn't see that race
with a cygwin window (and in fact, I'm not sure that the cygwin window
is relevant to the experiment either). I did verify it again in the case
of mingw.

So, I suggest we install you patch for now. Hopefully we'll find a way
to get rid of the race condition, but in the meantime, we have something
that makes the situation better.

> >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.

Ah, you're right, that would cause job_control to be set on cygwin,
I think. So that means we would probably want to emulate the __MSDOS__
case for mingw only.

-- 
Joel

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

[Christopher Faylor]

On Sun, May 11, 2008 at 09:40:43AM -0700, Joel Brobecker wrote:
>So, I suggest we install you patch for now. Hopefully we'll find a way
>to get rid of the race condition, but in the meantime, we have something
>that makes the situation better.

Sorry for the delay.  I'm travelling.

Checking this in is ok with me but it would be nice to consider a better
solution eventually.  Could you put a note to that effect in the patch (or
maybe you already did, I'm sort of computer challenged right now).

cgf

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

[Joel Brobecker]

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

Hi Chris,

> Checking this in is ok with me but it would be nice to consider a better
> solution eventually.  Could you put a note to that effect in the patch

Attached is the patch that I ended up checking in. Let me know if you'd
like me to make some adjustments to the comment...

2008-05-20  Joel Brobecker  <brobecker@adacore.com>

        * win32-nat.c (win32_wait): Block the control-c event while
        waiting for a debug event.

-- 
Joel

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

Index: win32-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/win32-nat.c,v
retrieving revision 1.151
diff -u -p -r1.151 win32-nat.c
--- win32-nat.c	11 Mar 2008 05:21:38 -0000	1.151
+++ win32-nat.c	20 May 2008 18:33:29 -0000
@@ -1458,7 +1458,25 @@ win32_wait (ptid_t ptid, struct target_w
 
   while (1)
     {
-      int retval = get_win32_debug_event (pid, ourstatus);
+      int retval;
+      
+      /* 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_win32_debug_event (pid, ourstatus);
+      SetConsoleCtrlHandler (NULL, FALSE);
+
       if (retval)
 	return pid_to_ptid (retval);
       else

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

[Christopher Faylor]

On Tue, May 20, 2008 at 11:38:20AM -0700, Joel Brobecker wrote:
>Hi Chris,
>
>> Checking this in is ok with me but it would be nice to consider a better
>> solution eventually.  Could you put a note to that effect in the patch
>
>Attached is the patch that I ended up checking in. Let me know if you'd
>like me to make some adjustments to the comment...
>
>2008-05-20  Joel Brobecker  <brobecker@adacore.com>
>
>        * win32-nat.c (win32_wait): Block the control-c event while
>        waiting for a debug event.

Looks good.  Thanks for persisting in getting this in.

cgf