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

["Alain Magloire" <alain@xxxxxxx>]

> 
> My understanding is that, unfortunately, there is not currently a
> portable way to do this.  Also I believe that long term the answer is
> to run gdb in async mode, and then ask gdb to interrupt the inferior.
> I'm given to believe that async doesn't work in all situations; Keith
> and Elena really would have to comment on that.  Hopefully they're
> reading and can speak to it.

Agreed, the long term solution: -async and send -exec-interrupt
to suspend the inferior.

> 
> Hmm, another choice in this area might be to make gdb its own process
> group leader, and then send the SIGINT to all the members of the
> process group.  I just thought of this and I'm not positive it would
> work though (gdb might interfere, for one thing).

But the child processes may not get clean when eclipse goes away,
it may be undesirable when debugging certain application.

> 
> You could also connect the pty to gdb's std*, and send a control-c
> through the pty.  This ought to work.  But this has the drawback that
> it doesn't let you separate out the inferior I/O (a heavy drawback
> imo).  (Did you try this?  You didn't mention it in your email, but
> there's a hint of it in org.eclipse.cdt.debug.mi.core.cdi.Configuration.)
> 

Heavy drawback.

> Alain> At this point, we consider Solaris gdb(5.2.0) buggy and there
> Alain> is no suspend for Solaris.
> 
> Yeah.  The gdb versioning problem is severe right now, because nobody
> ever completed the MI and async work.  So there's a window where
> things are buggy or incomplete :-(
> 

[.. snip ..]

> 
> There is hackery, but it doesn't require any new native code.
> 
> Alain> For application like vi etc .. the long term solution is
> Alain> probably to provide a Terminal Emulation.
> 
> Ouch.

To be clear, this not through gdb, but rather in Eclipse, extending the
console that is reading on the end of the master pty to do somethings like
catching/sending SIGWINCH, calling a ioctl() on the master if you resize
the Console panel etc ..
 
> Alain> Meanwhile, I'll be happy to put the xterm solution in if you
> Alain> can send the code/example, it should work for GNU/Linux and
> Alain> Solaris, it is probably a no go for QNX and windows(not
> Alain> X-Windows).
> 
> What you do is run xterm like so:
> 
> /bin/sh -c "xterm -e /bin/sh -c 'exec 1>&7; tty; exec /bin/cat 0<&6' 6<&0 7>&1"
> 
> Then you read the process' stdout to get the tty name.  When you want
> the xterm to exit, just close its stdin.  Yes, it is hideous.  Perhaps
> there's a way to simplify it.  One subtlety I do recall is that you
> can't redirect the inner process stdin before running `tty'; most
> versions of tty use stdin to find the controlling terminal.  (These
> days this isn't subtle -- it is documented :-)
> 
> This trick works with other common X-based terminal programs, too.
> For instance you can substitute `gnome-terminal -x' for `xterm -e'.
> It should be very portable across existing Unix variations.
> 

In brief.  The way we do things; creating a master/slave pty and spawning
gdb with -tty slave seems to work ok.
Advantages:
 - we can read/write on the master side so the input/output will appear on
   the eclipse console.  Which is a big plus over spawning 'xterm -e ...'
 - separation of the output from gdb.
 - can suspend correctly since gdb does share the same tty with the inferior
   so sending a SIGINT will stop the process.

Cons:
 - needs a Unix environment at least one that understand pseudo-terminals
 - Suspend still does not work on solaris i.e. On solaris if you try this:
    # gdb -i mi -tty /dev/pts/4 hello
    (gdb)
    r
    ^C^C^C           <------- hitting the keyboard CTRL-C
....
    (Changing xterm)
    # ps -ef |grep gdb
    # kill -2 gdb_pid

   The actions do not interrupt the process.  At this point we decide this a bug
   in gdb/solaris.

GNU/Linux: Works ok
Solaris: can not suspend
Cygwin:  ??