Re: sending CTRL-C to Cygwin gdb 6.8 has no effect

[John Cortell <rat042@freescale.com>]

At 03:11 PM 4/23/2010, Joel Brobecker wrote:
>This is as much as I know without having to look deeper into this,
>but that should give you enough info to figure out the rest...
>
>The change that improved the control-c behavior is the following one:
>
>| 2009-03-22   Nicolas Roche  <roche@adacore.com>
>|              Christopher Faylor <me+cygwin@cgf.cx>
>|
>|         * win32-nat.c (ctrl_c_handler): New function.
>|         (win32_wait): Register ctrl_c_handler as Ctrl-C handler if 
>the inferior
>|         is run in a separate console.
>
> > Hm. That document tells me that gdb itself can interrupt a remote
> > inferior, but how do I tell gdb to do so? I'm not a gdb expert, so
> > perhaps this is a dumb question.
>
>It depends of your environement, but basically, you press ctrl-c, or
>you get the IDE to send this ctrl-c to GDB.

Ah, OK so I assume you're saying the ability to interrupt a remote 
inferrior is in HEAD and not 6.8. Since sending CTRL-C to cygwin gdb 
6.8 is doing nothing for us when the inferior is local. I assume it 
would also do nothing for us if the inferior is remote.

So, my point is that with cygwin gdb 6.8, CDT has to send the CTRL-C 
to the local inferior in order to interrupt the program, since 
sending it to gdb has no effect. I was looking for confirmation that 
it's a known issue (and not something wrong we're doing). But as I 
say that, it occurs to me...why isn't the issue reproducible at the 
cmdline? I.e., if the user hitting CTRL-C in a Windows shell gdb 
session successfully interrupts the target program, why is sending 
the CTRL-C programatically not working? Any thoughts there?