From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23192 invoked by alias); 18 May 2006 17:23:58 -0000 Received: (qmail 23162 invoked by uid 22791); 18 May 2006 17:23:55 -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; Thu, 18 May 2006 17:22:54 +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 <20060518172252.JJYX15470.eastrmmtao02.cox.net@localhost.localdomain>; Thu, 18 May 2006 13:22:52 -0400 Received: from bob by localhost.localdomain with local (Exim 4.52) id 1FgmD9-0002s9-Jz; Thu, 18 May 2006 13:22:55 -0400 Date: Thu, 18 May 2006 17:44:00 -0000 From: Bob Rossi To: Jim Blandy Cc: Alain Magloire , gdb@sources.redhat.com Subject: Re: invoking GDB from FE and signals Message-ID: <20060518172253.GE21003@brasko.net> Mail-Followup-To: Jim Blandy , Alain Magloire , gdb@sources.redhat.com References: <3518719F06577C4F85DA618E3C37AB91054A9EFD@nimbus.ott.qnx.com> 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/msg00283.txt.bz2 > > 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. The other confusion point for me is that there is a magic ioctl that will send a signal to the tty process group. After looking in emacs, I'm thinking that the confusion was that there is an ioctl to get the character that needs to be written via 'write' to the pty in order to have the pty generate the signal. Look at the code below, is it true that the FE should just call 'write' but with the appropriate character. I find in emacs:process.c code that they send the SIGINT in different ways /* If possible, send signals to the entire pgrp by sending an input character to it. */ /* TERMIOS is the latest and bestest, and seems most likely to work. If the system has it, use it. */ case SIGINT: sig_char = &t.c_cc[VINTR]; break; ... send_process (proc, sig_char, 1, Qnil); which is simply getting the ^c char tha the terminal expects to send it or /* On Berkeley descendants, the following IOCTL's retrieve the current control characters. */ case SIGINT: ioctl (XINT (p->infd), TIOCGETC, &c); send_process (proc, &c.t_intrc, 1, Qnil); or /* On SYSV descendants, the TCGETA ioctl retrieves the current * control characters. */ case SIGINT: ioctl (XINT (p->infd), TCGETA, &t); send_process (proc, &t.c_cc[VINTR], 1, Qnil); or case SIGINT: send_process (proc, "\003", 1, Qnil); /* ^C */ goto whoosh; Thanks, Bob Rossi