From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17751 invoked by alias); 19 May 2006 02:54:58 -0000 Received: (qmail 17743 invoked by uid 22791); 19 May 2006 02:54:57 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 19 May 2006 02:54:55 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Fgv8f-0006NN-67; Thu, 18 May 2006 22:54:53 -0400 Date: Fri, 19 May 2006 03:00:00 -0000 From: Daniel Jacobowitz To: Jim Blandy , gdb@sources.redhat.com Subject: Re: invoking GDB from FE and signals Message-ID: <20060519025453.GA24453@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb@sources.redhat.com References: <3518719F06577C4F85DA618E3C37AB91054A9EFD@nimbus.ott.qnx.com> <20060518172253.GE21003@brasko.net> <20060519005831.GG21003@brasko.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060519005831.GG21003@brasko.net> User-Agent: Mutt/1.5.11+cvs20060403 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/msg00299.txt.bz2 On Thu, May 18, 2006 at 08:58:31PM -0400, Bob Rossi wrote: > Unless I'm wrong, and I often am!, I think the 'set tty' option that GDB > provides has a major limitation. If the FE uses it, it can't determine > which pty to send the SIGINT to when it recieves one. With this in mind, > I suggest a new solution that could go in several directions. > > The inferior and GDB should be run on the same pseudo terminal for the > reasons above. So moving the inferior to it's own terminal doesn't help > much. I suggest adding a new feature to GDB, something like > 'set gdb_io_tty /dev/pts/1' which would tell GDB what tty to output it's > I/O. However, GDB wouldn't change it's pty. This way, signals will be > delivered as if GDB was on the same terminal. Daniel, correct me if I'm > wrong, but this solution would work with the changes we made to the test > suite also. I think you're getting too caught up in the details of your current problem, and you've forgotten what you originally wanted to do. You want to be able to interrupt the inferior, if it is running, and GDB, if it is not. So why not make GDB handle that? It's GDB's job to keep track anyway. -- Daniel Jacobowitz CodeSourcery