From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4832 invoked by alias); 19 May 2006 00:59:07 -0000 Received: (qmail 4818 invoked by uid 22791); 19 May 2006 00:59:06 -0000 X-Spam-Check-By: sourceware.org Received: from eastrmmtao02.cox.net (HELO eastrmmtao02.cox.net) (68.230.240.37) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 19 May 2006 00:58:30 +0000 Received: from localhost.localdomain ([68.9.66.48]) by eastrmmtao02.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060519005828.IHRQ15470.eastrmmtao02.cox.net@localhost.localdomain>; Thu, 18 May 2006 20:58:28 -0400 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1FgtK4-0006UV-1p; Thu, 18 May 2006 20:58:32 -0400 Date: Fri, 19 May 2006 01:19:00 -0000 From: Bob Rossi To: Jim Blandy Cc: gdb@sources.redhat.com Subject: Re: invoking GDB from FE and signals Message-ID: <20060519005831.GG21003@brasko.net> Mail-Followup-To: Jim Blandy , gdb@sources.redhat.com References: <3518719F06577C4F85DA618E3C37AB91054A9EFD@nimbus.ott.qnx.com> <20060518172253.GE21003@brasko.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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/msg00292.txt.bz2 On Thu, May 18, 2006 at 10:44:48AM -0700, Jim Blandy wrote: > > Bob Rossi writes: > >> > We send the signal to the inferior ... the problem when running gdb is to > >> > ... get the inferior PID ... sigh. We have circumvent the problem is > >> > commercial products but did not fine a generic way to get the pid. > >> > >> You should use the 'set tty' command to run the user's program under > >> its own pseudo-tty, and then stuff the appropriate control characters > >> at the master side. That's the only way to do the right thing if the > >> inferior is doing job-control-like stuff, like a shell. > > > > OK, I agree with all of this, and Jim your comments have been extremly > > helpful. I'm left confused on 2 issues. > > > > Do I ever want to send a ^c signal to GDB? That is, if the inferior is > > not running, should I still send the ^c to the inferior's tty? If I'm > > supposed to send the ^c to GDB when it is running and to the inferior > > when it is running, then that is impossible from my point of view. And a > > good argument against using the tty command. > > I think you're coming at the problem in an odd way. You seem to be > thinking, "I've got this C-c --- what do I do with it?" Instead, > think about what facilities your user needs. Well, I'm realising, this certainly wouldn't be an issue if I didn't use the tty command. In fact, emacs doesn't use the tty command by default, so it handles all of this perfectly I'd imagine. The only downside that emacs has to deal with, is separating the gdb/mi output and the inferior output. This is discussed below. > - They need a way to stop their program and get control back to GDB. Yes. > - They may (or may not, it's not clear to me) need a way to interrupt > GDB when it's doing a long computation. Yes. As long as GDB handles this nicely in regards to the MI output. If the user can do this at the GDB console, the FE should support it, no? > There's a clear need for the first thing. The user's program isn't > behaving as expected; that's why they're debugging it. So you need to > provide some command to interrupt a running program. This can be > implemented by sending a SIGINT via the pty. Understood. I think that the discusion on HOW to send a signal to a pty has been answered very well. I do un > The second thing, I'm not sure you need. I mean, how many word > processors provide a way to interrupt some long internal computation > they're doing? If you do find a case like this, well, your front end > knows what it just asked GDB to do; when it sends some request that it > thinks might take a long time and would like to allow the user to > interrupt, it can tell the user interface about that and handle > requests to bail by sending a SIGINT to the GDB process itself. And > make sure your parser is prepared for whatever kind of malformed stuff > that produces (if it does; I don't know). Assuming I want to handle both of those case's like emacs does, I'm left with a problem because I use the 'set tty' command. For instance, I get a ^c, I need to send it somewhere because I don't know if GDB is running or if the inferior is running. 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. Another approach would be to act like valgrind does. That is, provide a file descriptor that GDB should write to. For instance, gdb --file-io=100, which would cause GDB to output it's I/O on file descriptor 100. This has a limitation in that it could possibly interface with the inferior outputting data on file descriptor 100. However, it would port to windows very nicely. Any comments? Anyways, thanks to everyone for helping me understand HOW to send a signal to a pty. This information was more than helpful. Thanks, Bob Rossi