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

[Dave Korn <dave.korn.cygwin@googlemail.com>]

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

    cheers,
      DaveK