Re: Separating "shell dir" output from GDB/MI output

[Daniel Jacobowitz <drow@false.org>]

On Sun, Oct 09, 2005 at 04:19:23PM -0400, Bob Rossi wrote:
> On Sun, Oct 09, 2005 at 04:02:48PM -0400, Daniel Jacobowitz wrote:
> > On Sun, Oct 09, 2005 at 01:33:20PM -0400, Bob Rossi wrote:
> > > It solves several problems. The user no longer has to create a pty to
> > > give to GDB to separate the inferior output and the console output.
> > > (CGDB will have to anyways, since it uses the terminal).
> > 
> > This one we've already solved, albeit with a bit of extra work on the
> > part of the frontend (and we were all enthusiastic about the solution,
> > too...)
> 
> Sorry, I honestly can't remember what your talking about. What was the
> solution for this that the front end had to do? Also, don't forget, on
> windows nativly, the front end *can't* open a PTY. Eli came up with this
> solution for that problem,
>    http://sources.redhat.com/ml/gdb-patches/2005-08/msg00047.html

All I mean is -inferior-set-tty.

> > > Some of the
> > > target's apparently write to STDOUT/STDERR, and that get's confused with
> > > the MI output.
> > 
> > I don't know what you're referring to here.
> 
> Oops, sorry. This is in the manual, and apparently is not true,
>    target-stream-output is the output produced by the target program.
>    All the target output is prefixed by `@'.
> We've had complaints by users that target output is not prefixed with
> '@'. So, I believe the output from the target can be intermingled with
> the MI output.

As far as I know this was never implemented except maybe for some remote
target.

> > > Finally, if we have several
> > > interpreters going at the same time, we could have them all output to
> > > there own descriptor.
> > 
> > This is an interesting idea, but I don't think it's an obviously right
> > choice.  The CLI frontend wants its own terminal, really.  The MI
> > interpreter only needs a pipe.  I have use for multiple MI interpreters
> > running at the same time, which will all need their own pipes, but
> > that's not a big deal with the infrastructure we already have.
> 
> This is interesting. How would you start up GDB in such a scenario? Say
> you wanted 2 MI interpreters running. What would you do?

One of them is for the frontend.  The other is for a Guile or Python
script being run, either by the user, or in a virtual "thread" in the
background watching for some interesting event.  Only one of them would
have "focus" at a time, i.e. accept input; the others would receive
some set of event notifications.

That's my theory anyway.  I started implementing this, and ran out of
steam.  I haven't been back to it in a while.

-- 
Daniel Jacobowitz
CodeSourcery, LLC