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

[John Cortell <rat042@freescale.com>]

At 09:13 PM 4/23/2010, Pedro Alves wrote:
>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.

OK. Now I get it. It was the 'themselves' in '[gdb] will catch the
CTRL_C_EVENT themselves' that made me think there was a 
misunderstanding. Now I see we're on the same page.


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

Great. That makes perfect sense now. So, given the behavior I'm 
seeing, it would seem the gdb that CDT launches is NOT sharing the 
console with the inferior. What is left for me to answer is "why?", 
since that's not what I expect. CDT, through an intermediary launcher 
process, does a  Win32 CreateProcess call to launch gdb. The call 
specifies whether to launch it attached or not, and if attached, 
whether to share the console. Fine, but that is between CDT's 
launcher process and gdb, not gdb and the inferior. The console 
relationship between gdb and the inferior seems out of the hands of 
CDT. That is, once we establish an mi connection with gdb, we till it 
to load aprogram.exe and run it. We don't specify whether gdb should 
share the console with it. So what's the expected behavior? Again, I 
would expect the two to share the console. After all, they apparently 
do when I carry out the same thing from a Windows command shell 
session. There too, I don't tell gdb to share a console with the 
inferior or not, and apparently it does.

OK. I'll give building cygwin gdb from HEAD a try, so I can have it 
around for reference. I appreciate your time on these questions, BTW. 
We're having a hell of a time interrupting the debugged program and 
hopefully this will help me get to the bottom of it.

John