Re: invoking GDB from FE and signals

[Jim Blandy <jimb at codesourcery dot com>]

Bob Rossi <bob_rossi@cox.net> writes:
> OK, I'm still wondering what the correct way to do this is. I came up
> with 5, maybe 6 distinct case's and am not sure which one is correct.
>
> I fork GDB on a pty. I also give the inferior it's own pty. So, there is
> 2 pty's. This unfortunatly, already makes things different than the user
> at the terminal just using GDB.

Right.  It means that you need to distinguish between:
- the user typing C-c at their running program, to get back to the GDB
  prompt, and
- the user typing C-c at GDB, to interrupt it while it's doing
  something else.

I assume you mean the former; I talked about this a bit more at the
bottom.

> 2. I can do a write (gdb_in, 1, "\3") to pass the ^c character to GDB's
>    stdin. 

This would send the interrupt signal to GDB, not to the inferior.
Given my assumption, this is no good.

> 3. I can do a write (inferior_in, 1, "\3") to pass the ^c character to the 
>    inferior's stdin.

This would send SIGINT to the inferior.  GDB will catch it, and report
that the program has been interrupted.  Good.  But it's sensitive to
the terminal's 'intr' character getting re-defined.

> 4. I can do a magic ioctl that sends a signal to GDB via GDB's pty.

No good, for the same reasons 2) is no good.

> 5. I can do a magic ioctl that sends a signal to the inferior via the 
>    inferior's pty.

This would be best, as it avoids worrying about the tty 'intr'
character.  But I couldn't find this ioctl in POSIX when I looked.

> 6. I can possible do a magic ioctl that sends a signal to the inferior via 
>    the GDB's pty.

There isn't anything that I know of that does this, and I don't see
any reason to do it.

> I'm wondering if using a seperate pty for the inferior makes this not
> possible all the time. For instance, with 1 pty, if GDB is running, then
> it will recieve the signal, but if the inferior is running, it will
> recieve the signal. With 2 pty's, does the FE need to know which is
> running (the pty or inferior) in order to know where to send the signal?

Well, if you want to behave exactly the way C-c does when running GDB
directly and sharing a tty with the inferior, yes.  But is that a good
idea?  You have a FE talking to GDB; do you really want the user to be
able to interrupt that conversation?

I think you should just say, C-c interrupts the inferior, not GDB, and
go with 3) or 5).  If you can find the ioctl.  Beware, POSIX wrapped
up the ioctls in functions, so you can't just search for ioctl in
Emacs.  You'll need to follow through the definition of the
interrupt-process Emacs Lisp function (in src/process.c).

> This is bad, because CGDB doesn't know if GDB or the inferior is
> currently running. Maybe when I finish the MI mode I'll know though.

And even if you did, there'd be race conditions: you send the C-c just
as GDB is reporting that the inferior has stopped, etc.