Re: invoking GDB from FE and signals

[Bob Rossi <bob_rossi@cox.net>]

On Thu, May 18, 2006 at 10:44:48AM -0700, Jim Blandy wrote:
> 
> 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.

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