From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2001 invoked by alias); 24 Apr 2010 02:13:25 -0000 Received: (qmail 1468 invoked by uid 22791); 24 Apr 2010 02:13:22 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 24 Apr 2010 02:13:16 +0000 Received: (qmail 1488 invoked from network); 24 Apr 2010 02:13:15 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 24 Apr 2010 02:13:15 -0000 From: Pedro Alves To: John Cortell Subject: Re: sending CTRL-C to Cygwin gdb 6.8 has no effect Date: Sat, 24 Apr 2010 02:13:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-20-generic; KDE/4.3.2; x86_64; ; ) Cc: gdb@sourceware.org, Joel Brobecker References: <201004231941.o3NJfbWR021914@az33smr01.freescale.net> <201004240209.55478.pedro@codesourcery.com> <201004240205.o3O25jIi000733@az33smr01.freescale.net> In-Reply-To: <201004240205.o3O25jIi000733@az33smr01.freescale.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004240313.12994.pedro@codesourcery.com> 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/msg00120.txt.bz2 On Saturday 24 April 2010 02:57:03, John Cortell wrote: > At 08:09 PM 4/23/2010, Pedro Alves wrote: > >On Friday 23 April 2010 21:25:10, John Cortell wrote: > > > cmdline? I.e., if the user hitting CTRL-C in a Windows shell gdb > > > session successfully interrupts the target program, why is sending > > > the CTRL-C programatically not working? Any thoughts there? > > > >In the latter case, is GDB sharing a console with the inferior? > >If not sharing a console (native debugging, that is), newer GDB's > >that postdate that patch Joel pointed you at, will catch the > >CTRL_C_EVENT themselves, and still try to interrupt the inferior > >with DebugBreakProcess. Older GDB's, like 6.8, do nothing. > > I'm not sure I explained myself correctly. You had. > When I said sending CTRL-C > programatically is not working, I meant, we're sending *gdb* the > CTRL-C and that's not working; it has no effect. Yes, I understood that correctly. > The expected > behavior is that the inferior get interrupted and gdb takes control. > Based on your comment, I believe you think we're sending the CTRL-C > to the inferior. I do not believe that. > We do that as a fallback, and that does indeed work, > but it's not an ideal solution. If nothing, we end up having to > special case for cygwin 6.8, which is messy. > > So, back to my question. If I'm able to manually do a CTRL-C within a > cygwin 6.8 gdb session running in a Windows command shell, and it > works, why doesn't it work when we (CDT) programatically send the gdb > process we launched the CTRL-C. That's the mystery at hand. I suspect > if we get an answer to that, it may help us address a range of issues > related to interrupting gdb on Windows. 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. 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. > >In the latter case, is GDB sharing a console with the inferior? > >If not sharing a console (native debugging, that is), newer GDB's > >that postdate that patch Joel pointed you at, will catch the > >CTRL_C_EVENT themselves, and still try to interrupt the inferior > >with DebugBreakProcess. Older GDB's, like 6.8, do nothing. > >With remote debugging, I think sending a ctrl-c to > >GDB should work, even in 6.8 (provided there's a console > >and GDB does get the CTRL_C_EVENT, or if this is a cygwin gdb, > >you sent it a real SIGINT signal). Did you try it? -- Pedro Alves