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

[John Cortell <rat042 at freescale dot com>]

At 08:09 PM 4/23/2010, Pedro Alves wrote:
> On Friday 23 April 2010 21:25:10, John Cortell wrote:
> > 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?
>
> In the latter case, is GDB sharing a console with the inferior?
> If not sharing a console (native debugging, that is), newer GDB's
> that postdate that patch Joel pointed you at, will catch the
> CTRL_C_EVENT themselves, and still try to interrupt the inferior
> with DebugBreakProcess.  Older GDB's, like 6.8, do nothing.

I'm not sure I explained myself correctly. When I said sending CTRL-C 
programatically is not working, I meant, we're sending *gdb* the 
CTRL-C and that's not working; it has no effect. The expected 
behavior is that the inferior get interrupted and gdb takes control. 
Based on your comment, I believe you think we're sending the CTRL-C 
to the inferior. We do that as a fallback, and that does indeed work, 
but it's not an ideal solution. If nothing, we end up having to 
special case for cygwin 6.8, which is messy.

So, back to my question. If I'm able to manually do a CTRL-C within a 
cygwin 6.8 gdb session running in a Windows command shell, and it 
works, why doesn't it work when we (CDT) programatically send the gdb 
process we launched the CTRL-C. That's the mystery at hand. I suspect 
if we get an answer to that, it may help us address a range of issues 
related to interrupting gdb on Windows.






> With remote debugging, I think sending a ctrl-c to
> GDB should work, even in 6.8 (provided there's a console
> and GDB does get the CTRL_C_EVENT, or if this is a cygwin gdb,
> you sent it a real SIGINT signal).  Did you try it?
>
> --
> Pedro Alves