Re: [cdt-debug-dev] CDT debug and ptys

["Alain Magloire" <alain@xxxxxxx>]

> 
> Sebastien --
> 
> John asked me to get in touch with you in re: handling ptys and
> inferior I/O in the debug component, specifically as these things
> relate to gdb.
> 
> I'm still a bit vague on what exactly you'd like to know.  I'll start
> with a brief overview.
> 
> Historically, inferior I/O support in gdb has not been very good.  I
> think Keith and Elena are or will be working on this.
> 
> Sometimes, even whatever gdb provides won't suffice.  For instance,
> one might want to debug a program that wants to run in a real
> terminal, like vi or the gdb tui.  One idea here is, rather than
> implementing a new terminal inside Eclipse, just give the user the
> option of forking an xterm and then using that as the inferior tty.
> This is what we did in Insight.
> 
> In less extreme situations, it seems nicer for the user for the output
> to appear in a console window inside the debug environment.  This is
> the area where gdb is less than proficient.  I'm not exactly sure what
> will be happening here, but I imagine it will involve gdb wrapping the
> inferior's output in some MI way.
> 
> I notice you're already creating a new pty and passing it to gdb using
> the `-tty' option.  This is another viable alternative (for the
> non-full-screen-inferior mode); I played with an implementation of
> this in Insight (it never went in due to portability concerns; luckily
> Eclipse's requirements here seem less stringent).
>

We were trying to find a portable solution and in the brouhaha of the
exchange this got view as a QNX specific problem.

So you have pointed out:
 1) for remote debug and graphical application, how to get the display
 2) for remote/native debug  how to get the console output(in gdb/mi stream)
 3) for applications that need a tty i.e. vi, emacs, login etc ..
 4) for native how to suspend/stop/interrupt a running program

We solve some of the points above, but it was QNX specifics and we were looking
for more portable solutions.

So far the ___only__ thing we were trying to solve was (4) suspend a
running application.  Terminal emulation etc .. could come later.

The approach was to send SIGINT to gdb:
- since java as no concept of signal and pid, the java.lang.Process class
was extended with JNI code to be able to get PID and send signals, see:
(org.eclipse.cdt.core/utils/org/eclipse/cdt/utils/spawner.Spawner.java) and the fragment
(org.eclipse.cdt.core.linux/library/spawner.c) for the JNI code.

But it was not enough, it turns out, for native debug, gdb relies on the behaviour
of the terminal to propagate the SIGINT(when you hit the keyboard CTL-C) sending
a kill -2 gdb_pid(via Spawner.java:interrupt()) did not work,
and we did not have the pid of the inferior.

We changed things around by starting gdb with '-tty' since in this case
gdb and the inferior did not share the tty, gdb was correctly
relaying the SIGINT to the inferior ... but it only works on GNU/Linux.
For example this will not work on Solaris.
At this point, we consider Solaris gdb(5.2.0) buggy and there is no suspend
for Solaris.

Using '-tty' also solve point (2) for GNU/Linux.

But Windows is still a problem, not sure what -tty means for Cygwin/gdb.

The xterm solution, you are proposing above will not work for windows either.
Question: how do you get the xterm's tty? Are we talking JNI code or is there
some xterm/shell hackery to find the tty portably.

For application like vi etc .. the long term solution is probably to provide
a Terminal Emulation.  Meanwhile, I'll be happy to put the xterm solution in if you
can send the code/example, it should work for GNU/Linux and Solaris,
it is probably a no go for QNX and windows(not X-Windows).