From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15573 invoked by alias); 25 Apr 2010 14:10:29 -0000 Received: (qmail 15565 invoked by uid 22791); 25 Apr 2010 14:10:28 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from az33egw02.freescale.net (HELO az33egw02.freescale.net) (192.88.158.103) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 25 Apr 2010 14:10:20 +0000 Received: from az33smr01.freescale.net (az33smr01.freescale.net [10.64.34.199]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id o3PE9tVY011077; Sun, 25 Apr 2010 07:09:55 -0700 (MST) Received: from suki.freescale.com (mvp-10-214-73-35.am.freescale.net [10.214.73.35]) by az33smr01.freescale.net (8.13.1/8.13.0) with ESMTP id o3PEIBMG000580; Sun, 25 Apr 2010 09:18:12 -0500 (CDT) Message-Id: <201004251418.o3PEIBMG000580@az33smr01.freescale.net> Date: Sun, 25 Apr 2010 14:10:00 -0000 To: Dave Korn From: John Cortell Subject: Re: sending CTRL-C to Cygwin gdb 6.8 has no effect Cc: Pedro Alves , gdb@sourceware.org, Joel Brobecker In-Reply-To: <4BD389B3.2030409@gmail.com> References: <201004231941.o3NJfbWR021914@az33smr01.freescale.net> <201004240209.55478.pedro@codesourcery.com> <201004240205.o3O25jIi000733@az33smr01.freescale.net> <201004240313.12994.pedro@codesourcery.com> <201004242238.o3OMc6O6015080@az33smr01.freescale.net> <4BD389B3.2030409@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-04/txt/msg00130.txt.bz2 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 '. 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