From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29365 invoked by alias); 15 May 2006 19:04:33 -0000 Received: (qmail 29350 invoked by uid 22791); 15 May 2006 19:04:30 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao05.cox.net (HELO eastrmmtao05.cox.net) (68.230.240.34) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 15 May 2006 19:04:28 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao06.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060515181735.CJLM16402.eastrmmtao06.cox.net@localhost.localdomain>; Mon, 15 May 2006 14:17:35 -0400 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1Ffhe9-00054u-FM; Mon, 15 May 2006 14:18:21 -0400 Date: Mon, 15 May 2006 19:18:00 -0000 From: Bob Rossi To: PAUL GILLIAM Cc: Daniel Jacobowitz , gdb@sourceware.org Subject: Re: invoking GDB from FE and signals Message-ID: <20060515181821.GA18932@brasko.net> References: <20060513141920.GC10678@brasko.net> <20060513145421.GA3664@nevyn.them.org> <20060513151026.GD10678@brasko.net> <20060513151057.GA4112@nevyn.them.org> <20060513152021.GE10678@brasko.net> <20060513154816.GA5022@nevyn.them.org> <1147712871.3672.153.camel@dufur.beaverton.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1147712871.3672.153.camel@dufur.beaverton.ibm.com> User-Agent: Mutt/1.5.9i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00214.txt.bz2 On Mon, May 15, 2006 at 10:07:51AM -0700, PAUL GILLIAM wrote: > On Sat, 2006-05-13 at 11:48 -0400, Daniel Jacobowitz wrote: > > On Sat, May 13, 2006 at 11:20:21AM -0400, Bob Rossi wrote: > > > When I say "the supported way", I'm assuming there is a way GDB provides > > > for FE's to work with it in regards to sending signals, in particularly > > > ^c. > > > > But there isn't :-) > > > > > If GDB doesn't provide this functionality and it's mere hackers > > > chance that all of us FE's are getting this to work most of the time, > > > then I understand what you mean. > > > > > > Othewise, if GDB has been designed to accept signal during certain > > > circumstances, and not during others, I would love to know what those > > > are so that I can benefit from using this functionality. > > > > If there were such a design, hopefully, it would be in the manual. All > > of this is generally legacy from the GDB CLI, which is designed to work > > with the host's job control. When the inferior is running and you > > press Control-C, the signal goes to the inferior, not to GDB. > > > > Your needs may be different. > > Just to add a little detail about the 'normal' case: You press > , the tty handler intercepts it and sends a signal to the > inferior. Because the inferior is being debugged, *any* signal causes > it to stop, letting the debugger know that it stopped due to a > particular signal. When gdb causes the inferior to run again, gdb > decides if the signal should be 'passed through' to the inferior'. > > I hope I'm not being pedantic. OK, here's what happens from the FE perspective though. You type ^c. The FE get's the signal (which is in a different process group than GDB), and passes the signal to GDB with 'kill (gdb_pid, SIGINT)'. Even though the inferior is running, GDB is getting the signal. What happens from this point? Also, the 2 interesting case's might be when the inferior is on the same PTY as GDB and on a different PTY. Thanks, Bob Rossi