Re: invoking GDB from FE and signals

[Jim Blandy <jimb at codesourcery dot com>]

Bob Rossi <bob_rossi@cox.net> 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.

- They need a way to stop their program and get control back to GDB.
- They may (or may not, it's not clear to me) need a way to interrupt
  GDB when it's doing a long computation.

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.

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).

> 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;

You're right.  I had been sure there was some way to just get the pty
to send the signal to its current process group directly, but this
seems to be the way it's done.

(My advice: just implement the TERMIOS case, and wait until people
complain before you worry about the other cases.  That Emacs code is
very old, and the termios interface is very widely available these
days.)