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

[John Cortell <rat042 at freescale dot 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?