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

Pedro Alves
2010-04-24T02:13:25Z

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