From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29335 invoked by alias); 19 May 2006 10:59:47 -0000 Received: (qmail 29326 invoked by uid 22791); 19 May 2006 10:59:47 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao04.cox.net (HELO eastrmmtao04.cox.net) (68.230.240.35) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 19 May 2006 10:59:43 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao04.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060519105940.OMU9931.eastrmmtao04.cox.net@localhost.localdomain>; Fri, 19 May 2006 06:59:40 -0400 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1Fh2ht-000644-H9; Fri, 19 May 2006 06:59:45 -0400 Date: Fri, 19 May 2006 12:49:00 -0000 From: Bob Rossi To: Jim Blandy , gdb@sources.redhat.com Subject: Re: invoking GDB from FE and signals Message-ID: <20060519105945.GC31982@brasko.net> Mail-Followup-To: Jim Blandy , gdb@sources.redhat.com References: <3518719F06577C4F85DA618E3C37AB91054A9EFD@nimbus.ott.qnx.com> <20060518172253.GE21003@brasko.net> <20060519005831.GG21003@brasko.net> <20060519025453.GA24453@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060519025453.GA24453@nevyn.them.org> 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/msg00307.txt.bz2 On Thu, May 18, 2006 at 10:54:53PM -0400, Daniel Jacobowitz wrote: > 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. Well, you could be correct. However, I need to both send a signal to the pty, and know where to send it to. There kind of lumped together. > 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. OK, you could not be more correct. I want GDB to handle it, not the FE. However, how do I let "GDB handle it", while using the 'set tty' command? I guess that's the question I've been asking all along. There is 3 choices, and 1 of them is not possible for me, which leaves 2 choices. Does either of these allow GDB to just handle it? - always send the ^c to GDB's pty - always send the ^c to inferior's pty - send the ^c to the active GDB or inferior. With 'set tty' this becomes a problem that doesn't exist otherwise. Thanks, Bob Rossi