From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29719 invoked by alias); 22 May 2006 22:37:58 -0000 Received: (qmail 29711 invoked by uid 22791); 22 May 2006 22:37: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; Mon, 22 May 2006 22:37:55 +0000 Received: (qmail 25794 invoked from network); 22 May 2006 22:37:53 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 22 May 2006 22:37:53 -0000 To: gdb@sources.redhat.com Subject: Re: invoking GDB from FE and signals References: <3518719F06577C4F85DA618E3C37AB91054A9EFD@nimbus.ott.qnx.com> <20060518172253.GE21003@brasko.net> <20060519005831.GG21003@brasko.net> <20060519025453.GA24453@nevyn.them.org> <20060519105945.GC31982@brasko.net> <20060519124919.GB750@nevyn.them.org> <20060519134221.GC26750@brasko.net> <20060519175522.GA30002@brasko.net> From: Jim Blandy Date: Tue, 23 May 2006 03:46:00 -0000 In-Reply-To: <20060519175522.GA30002@brasko.net> (Bob Rossi's message of "Fri, 19 May 2006 13:55:22 -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/msg00332.txt.bz2 Bob Rossi writes: > On Fri, May 19, 2006 at 10:17:02AM -0700, Jim Blandy wrote: >> >> Bob Rossi writes: >> > On Fri, May 19, 2006 at 08:49:19AM -0400, Daniel Jacobowitz wrote: >> >> On Fri, May 19, 2006 at 06:59:45AM -0400, Bob Rossi wrote: >> >> > 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. >> >> >> >> Make it trap the SIGINT and do something sensible with it. >> > >> > OK, so, does anyone think this suggestion would have drawbacks? >> > That is, modify GDB so that the FE can always send the signal to the GDB >> > pty, and GDB will figure out what to do with the signal. This would be a >> > wonderful solution. That way, if the FE is using 'set tty' or not, it >> > could always send the signal to the same place. >> >> I totally think you should be using 'set tty'. It's the only way to >> keep inferior and GDB output straight, and nobody has ever had the >> forbearance to explain the drawbacks to me. >> >> I still think it's odd that you would actually want a way to send a >> SIGINT to either the inferior if running or GDB otherwise. But if you >> really do want that, then making GDB deal with it seems like the right >> thing. > > Jim, the user can do this exact sort of thing just using plain old GDB. > They don't even know they are doing it probably, they just hit ^c. So, > it's not that I want to send ^c to GDB or inferior, I just want to do > what the user wants. > > OK, I have to assume you know more about this than I do. You've been > doing it for much longer. Where does your FE send the ^c when GDB is > running? when inferior is running? I don't have an FE of my own. I'm just working from my understanding of how the design is supposed to support what you're trying to do. I understand that the disposal of C-c in plain old GDB depends on whether the inferior is running or not. But is that a feature? What happens when the user hits C-c just as their program hits a breakpoint? Probably GDB will behave just fine, but if it had undertaken something interruptible in response to the breakpoint, then the reaction of the system to the user's keystroke --- a breakpoint hit, and then the interruption of something the user hadn't expected --- is pretty confusing. As I've said, if I were implementing an FE, I would provide a command to interrupt the inferior, implemented by sending a signal via the pty, and I wouldn't provide a command to interrupt GDB; I'd try to change the way I interacted with GDB to avoid long pauses, or display progress bars, or something like that.