This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: MI interface
On Wed, Sep 18, 2002 at 09:05:33AM -0700, Keith Seitz wrote:
> On Wed, 18 Sep 2002, Arjan van Dijk wrote:
>
> > >Why does gdb redirect the stdout to itself? I mean due to this all programs
> >
> > and I would like to know too!
>
> http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=623&return_url=http%3A%2F%2Fsources.redhat.com%2Fcgi-bin%2Fgnatsweb.pl%3Fdatabase%3Dgdb%26category%3Dall%26severity%3Dall%26priority%3Dall%26responsible%3Dall%26submitter_id%3Dall%26state%3Dall%26ignoreclosed%3DIgnore%2520Closed%26class%3Dall%26synopsis%3D%26multitext%3D%26columns%3Dcategory%26columns%3Dstate%26columns%3Dclass%26columns%3Dresponsible%26columns%3Dsynopsis%26displaydate%3DDisplay%2520Current%2520Date%26cmd%3Dsubmit%2520query%26sortby%3DResponsible%26.cgifields%3Dcolumns%26.cgifields%3Doriginatedbyme%26.cgifields%3Ddisplaydate%26.cgifields%3Dignoreclosed
>
> Basically the problem is that in order for this to work on a native
> target, that target must be async. Right now there are no async native
> targets. I hope to correct that when I've got some more cycles.
>
> This is still a very, very tricky situation, though. While many programs
> will work with just this target output, I would suspect that many
> applications simply won't work (well) this way. Imagine trying to debug
> emacs or vi -- the developer is almost certainly going to want to use a
> separate tty for the inferior. Unless the UI developer is willing (or
> crazy enough) to implement a terminal emulator in the IDE/GUI, these more
> sophisticated programs just aren't going to work properly.
It's not hard to make the program run in a new xterm/separate 'screen'
session/different virtual console. It would be reasonable to
centralize the code to do this and include it with GDB. One way to do
it is to provide an application which reads from a socket or FIFO,
communicates with GDB in a simple protocol, and handles all
input/output. Then you can exec 'screen helper tcp:4111' or use an
xterm or openvt equivalent or what-have-you.
Of course, what should be done with the output packets in MI etc. is
not clear. Probably "reported via MI console" would be a fourth option
to screen/xterm/openvt; generally you either want to see the program's
output in a separate window OR you want your debugger/testing tool to
see it, not both.
This could even extend to running a program in a host xterm on a remote
gdbserver over TCP/IP, much more nicely than the current method.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer