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

[Bob Rossi <bob at brasko dot net>]

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:
> > > > On 10/9/05, Bob Rossi <bob@brasko.net> wrote:
> > > > > I think the best idea we've had so far for solving problems like this is
> > > > > to add an option to GDB to have it output GDB/MI data on a file
> > > > > descriptor X. For instance,
> > > > >    gdb -i=mi -mi-out-fd=30
> > > > > and then when you fork/exec GDB you dup the 30 file descriptor so that
> > > > > you can read the output.
> > > > >
> > > > > Eli, do you know if this approach would be portable to windows nativly?
> > > > > I could look into implementing this feature, since it would resolve a
> > > > > *lot* of problems regarding I/O.
> > > 
> > > While I think this is a good idea, what other specific problems would
> > > it solve that we haven't solved already?
> > 
> > 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

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

> > Also, thing's like 'shell' and potentially other case's
> > get mixed in with the MI output.
> 
> Shell's the only one I can think of offhand.

Yeah, me too. Darn shell command always break's front ends :(

> > 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?

> I think wrapping shell's output in MI quoting would be a simpler
> solution rather than changing the nature of MI/frontend interaction
> again.

Yeah, you sound correct on this point.

Bob Rossi