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

John Cortell
2010-04-23T20:27:27Z

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?