From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19123 invoked by alias); 18 May 2006 01:21:43 -0000 Received: (qmail 19107 invoked by uid 22791); 18 May 2006 01:21:40 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao01.cox.net (HELO eastrmmtao01.cox.net) (68.230.240.38) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 18 May 2006 01:21:38 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao01.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060518012134.UIHJ17255.eastrmmtao01.cox.net@localhost.localdomain>; Wed, 17 May 2006 21:21:34 -0400 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1FgXCr-0002m0-0b; Wed, 17 May 2006 21:21:37 -0400 Date: Thu, 18 May 2006 01:40:00 -0000 From: Bob Rossi To: PAUL GILLIAM Cc: gdb@sourceware.org Subject: Re: invoking GDB from FE and signals Message-ID: <20060518012136.GB27052@brasko.net> References: <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> <20060515181821.GA18932@brasko.net> <20060515191714.GA5918@nevyn.them.org> <20060515194313.GA21608@brasko.net> <1147719922.3672.159.camel@dufur.beaverton.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1147719922.3672.159.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/msg00270.txt.bz2 On Mon, May 15, 2006 at 12:05:22PM -0700, PAUL GILLIAM wrote: > On Mon, 2006-05-15 at 15:43 -0400, Bob Rossi wrote: > > On Mon, May 15, 2006 at 03:17:14PM -0400, Daniel Jacobowitz wrote: > > > On Mon, May 15, 2006 at 02:18:21PM -0400, Bob Rossi wrote: > > > > 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)'. > > > > > > Jim just explained this, but it may not have been clear: that is the > > > wrong way to forward the signal. If you are running GDB on a > > > pseudo-tty, you need to forward the job control signal to that TTY, not > > > to the GDB process itself. > > > > > > I don't really know how to do that. Is it by setting BRKING in > > > termios? There's something about TIOCSIGNAL too. Lots of code for > > > this in emacs. > > > > I'm totally confused. I'm certainly not an expert, but sending a signal > > can only be done to a pid using kill. What other ways are there? > > > > Bob Rossi > > Two things: > 1) Yes the only way to send a signal to a *pid* is with kill. But which > pid? DO NOT SEND THE SIGNAL TO GDB! Send it to GDB's inferior. > 2) Danial is not asking you to send a signal to a pty, he is asking you > to send a signal to GDB's inferior *via* the pty, by using an ioctl > function and suggesting that code exists in EMACS to do just that. OK, I'm still wondering what the correct way to do this is. I came up with 5, maybe 6 distinct case's and am not sure which one is correct. I fork GDB on a pty. I also give the inferior it's own pty. So, there is 2 pty's. This unfortunatly, already makes things different than the user at the terminal just using GDB. 1. I can send a kill (gdb_pid, SIGINT) to GDB, but everyone thinks that is a bad idea. 2. I can do a write (gdb_in, 1, "\3") to pass the ^c character to GDB's stdin. 3. I can do a write (inferior_in, 1, "\3") to pass the ^c character to the inferior's stdin. 4. I can do a magic ioctl that sends a signal to GDB via GDB's pty. 5. I can do a magic ioctl that sends a signal to the inferior via the inferior's pty. 6. I can possible do a magic ioctl that sends a signal to the inferior via the GDB's pty. Can someone please suggest the correct solution to this problem? I'm wondering if using a seperate pty for the inferior makes this not possible all the time. For instance, with 1 pty, if GDB is running, then it will recieve the signal, but if the inferior is running, it will recieve the signal. With 2 pty's, does the FE need to know which is running (the pty or inferior) in order to know where to send the signal? This is bad, because CGDB doesn't know if GDB or the inferior is currently running. Maybe when I finish the MI mode I'll know though. Bob Rossi