From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9022 invoked by alias); 18 May 2006 03:36:58 -0000 Received: (qmail 9013 invoked by uid 22791); 18 May 2006 03:36:57 -0000 X-Spam-Check-By: sourceware.org Received: from intranet.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.6) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 18 May 2006 03:36:56 +0000 Received: (qmail 10223 invoked from network); 18 May 2006 03:36:54 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 May 2006 03:36:54 -0000 To: Bob Rossi Cc: PAUL GILLIAM , gdb@sourceware.org Subject: Re: invoking GDB from FE and signals 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> <20060518012136.GB27052@brasko.net> From: Jim Blandy Date: Thu, 18 May 2006 12:32:00 -0000 In-Reply-To: <20060518012136.GB27052@brasko.net> (Bob Rossi's message of "Wed, 17 May 2006 21:21:36 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00273.txt.bz2 Bob Rossi writes: > 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. Right. It means that you need to distinguish between: - the user typing C-c at their running program, to get back to the GDB prompt, and - the user typing C-c at GDB, to interrupt it while it's doing something else. I assume you mean the former; I talked about this a bit more at the bottom. > 2. I can do a write (gdb_in, 1, "\3") to pass the ^c character to GDB's > stdin. This would send the interrupt signal to GDB, not to the inferior. Given my assumption, this is no good. > 3. I can do a write (inferior_in, 1, "\3") to pass the ^c character to the > inferior's stdin. This would send SIGINT to the inferior. GDB will catch it, and report that the program has been interrupted. Good. But it's sensitive to the terminal's 'intr' character getting re-defined. > 4. I can do a magic ioctl that sends a signal to GDB via GDB's pty. No good, for the same reasons 2) is no good. > 5. I can do a magic ioctl that sends a signal to the inferior via the > inferior's pty. This would be best, as it avoids worrying about the tty 'intr' character. But I couldn't find this ioctl in POSIX when I looked. > 6. I can possible do a magic ioctl that sends a signal to the inferior via > the GDB's pty. There isn't anything that I know of that does this, and I don't see any reason to do it. > 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? Well, if you want to behave exactly the way C-c does when running GDB directly and sharing a tty with the inferior, yes. But is that a good idea? You have a FE talking to GDB; do you really want the user to be able to interrupt that conversation? I think you should just say, C-c interrupts the inferior, not GDB, and go with 3) or 5). If you can find the ioctl. Beware, POSIX wrapped up the ioctls in functions, so you can't just search for ioctl in Emacs. You'll need to follow through the definition of the interrupt-process Emacs Lisp function (in src/process.c). > 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. And even if you did, there'd be race conditions: you send the C-c just as GDB is reporting that the inferior has stopped, etc.