From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2001 invoked by alias); 24 Apr 2010 23:56:46 -0000 Received: (qmail 1993 invoked by uid 22791); 24 Apr 2010 23:56:45 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM X-Spam-Check-By: sourceware.org Received: from mail-wy0-f169.google.com (HELO mail-wy0-f169.google.com) (74.125.82.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 24 Apr 2010 23:56:41 +0000 Received: by wyf19 with SMTP id 19so1306230wyf.0 for ; Sat, 24 Apr 2010 16:56:38 -0700 (PDT) Received: by 10.216.85.140 with SMTP id u12mr2616783wee.78.1272153398596; Sat, 24 Apr 2010 16:56:38 -0700 (PDT) Received: from [192.168.2.99] (cpc2-cmbg8-0-0-cust61.cmbg.cable.ntl.com [82.6.108.62]) by mx.google.com with ESMTPS id r29sm9434881wbv.15.2010.04.24.16.56.36 (version=SSLv3 cipher=RC4-MD5); Sat, 24 Apr 2010 16:56:37 -0700 (PDT) Message-ID: <4BD389B3.2030409@gmail.com> Date: Sat, 24 Apr 2010 23:56:00 -0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: John Cortell CC: Pedro Alves , gdb@sourceware.org, Joel Brobecker Subject: Re: sending CTRL-C to Cygwin gdb 6.8 has no effect 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> In-Reply-To: <201004242238.o3OMc6O6015080@az33smr01.freescale.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00128.txt.bz2 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