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

[Pedro Alves <pedro@codesourcery.com>]

On Saturday 24 April 2010 02:57:03, John Cortell wrote:
> 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.

You had.

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

Yes, I understood that correctly.

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

I do not believe that.

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


I already answered that.  I'll try again.  In the latter case (when CDT
sends gdb the CTRL-C), if GDB is _not_ sharing a console with the inferior,
only GDB will get the CTRL_C_EVENT (that's how Windows works).  Before
the patch that Joel pointed you at (GDB 6.8 does not have that patch),
a CTRL_C_EVENT sent to GDB when the inferior is running does nothing.
The patch Joel pointed you at, made it so that when GDB gets a
CTRL_C_EVENT, and, gdb knows it is not sharing a console with the
inferior, then gdb knows that the inferior hasn't seen the CTRL_C_EVENT
as well, so it needs to take the job of interrupting the inferior
itself with DebugBreakProcess.  GDB 6.8 does not have that patch
applied, GDB simply ignores the CTRL_C_EVENT --- it does nothing,
as you say.  Try a more recent GDB, and things will probably work
a bit better.  Building a Cygwin GDB is very easy, there's nothing
to it (install a few devel packages using Cygwin's setup.exp;
./configure; make).  It would be quite helpful if frontend people
once in a while tried out top of tree (or recent) GDBs.

In a Windows command shell session (the former case you describe
as working), GDB _is sharing_ a console with the inferior, so
ctrl-c generates an event in all processes in the console
process group.  That is, the inferior also gets a CTRL_C_EVENT
automatically generated by Windows itself.  GDB intercepts this
event, like any other debug event, and reports it as SIGINT to the
frontend.  In this case, GDB _also_ receives the CTRL_C_EVENT event,
but, since it knows it is sharing the console with the inferior, it
simply ignores it.  Again, older GDBs, like 6.8, _always_ ignored
this CTRL_C_EVENT they themselves get; they didn't even install a
handler.

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

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