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

[John Cortell <rat042@freescale.com>]

At 07:15 PM 4/24/2010, Dave Korn wrote:
>On 24/04/2010 23:29, John Cortell wrote:
>
> > 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.
>
>   What's probably getting in the way here is Cygwin's POSIX tty emulation,
>which has to interact with the Windows console in bizarre and sometimes
>unexpected ways.  A Cygwin process launched from a standard Windows console -
>whether cmd.exe or bash doesn't matter - comes with its stdio handles attached
>to the console.
>
>   However, a Cygwin process launched either from a shell running in 
> one of the
>GUI consoles like xterm/rxvt, or if launched with CYGWIN=tty set in the
>environment, gets connected to a pty, which is implemented in windows terms as
>the ends of a pair of (iirc) named pipes.  In that case, no console is created
>nor attached to the process, to avoid the "flashing black window" syndrome
>caused by a console appearing briefly even if you hide it.
>
>   I haven't checked what the code in gdb exactly tries to do when it launches
>a process, but I'd infer from your observations that when the gdb itself is
>running attached to a console it launches the inferior sharing the console,
>and when not it may well let the new process create its own console.
>
>   I quickly searched for "console" in the gdb info page, and discovered a
>couple of useful-sounding options:
>
> > `set new-console MODE'
> >      If MODE is `on' the debuggee will be started in a new console on
> >      next start.  If MODE is `off'i, the debuggee will be started in
> >      the same console as the debugger.
> >
> > `show new-console'
> >      Displays whether a new console is used when the debuggee is
> >      started.
> >
> > `set new-group MODE'
> >      This boolean value controls whether the debuggee should start a
> >      new group or stay in the same group as the debugger.  This affects
> >      the way the Windows OS handles `Ctrl-C'.
> >
> > `show new-group'
> >      Displays current value of new-group boolean.
>
>   Those sound like they ought to be of some use to you in this situation :)


Dave, that all got me pretty optimistic our problems would soon be 
over :-). Unfortunately, none of it panned out.

1. I ruled out POSIX emulation in the inferior being a factor by 
debugging a MinGW-built program. No change in behavior.CTRL-C to gdb 
programatically has no effect.
2. I added 'set new-console off' in the .gdbinit file (and confirmed 
it took effect with a 'show new-console' at debug time). No change in behavior.
3. I added 'set new-group on' in the .gdbinit file (and confirmed it 
took effect with a 'show new-group' at debug time). The default is 
on, btw. No change in behavior.

So, I decided to look at how we send the CTRL-C to gdb. If the 
program spawned by our launcher is using the cygwin runtime dll, we 
run  a 'kill -SIGINT <PID>'. In this case, the launched program is 
cygwin's gdb, which does use the cygwin runtime, so that's what we 
end up doing. And for sure, this command isn't interrupting either 
gdb or the inferior. So what I'll do tomorrow is see if we have more 
luck using the Win32 call GenerateConsoleCtrlEvent(CTRL_C_EVENT , 
0)...that's what we use when the launched program is not using the 
cygwin runtime.

Anyone know of a way to tell whether two running processes on Windows 
are sharing a console...perhaps via some utility? Process Explorer 
doesn't seem to reveal that information.

Again, I appreciate the insight.
John