Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-debug-dev] CDT debug and ptys

Alain>  4) for native how to suspend/stop/interrupt a running program

Alain> The approach was to send SIGINT to gdb:

Alain> We changed things around by starting gdb with '-tty' since in this case
Alain> gdb and the inferior did not share the tty, gdb was correctly
Alain> relaying the SIGINT to the inferior ... but it only works on GNU/Linux.

Ok.  Thanks.

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.

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

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

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 :-(

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

Me neither.  Especially when debugging a non-Cygwin inferior.

Alain> The xterm solution, you are proposing above will not work for
Alain> windows either.

True.  It seems unlikely to me that a really portable solution will be
found here.

Alain> Question: how do you get the xterm's tty? Are we talking JNI
Alain> code or is there some xterm/shell hackery to find the tty
Alain> portably.

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.

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.

Tom


Back to the top