Separating "shell dir" output from GDB/MI output

Separating "shell dir" output from GDB/MI output

[jingzhao.ou]

Dear all,

I am trying to see if it is possible to build a Tcl/Tk based GDB
frontend using Bob Rossi's MI parser. For normal commands, it works
just fine. However, if I execute "shell dir" command in gdb, the
parser will report error. (see the end of the email)

I am wondering if there is any way to separate the shell output from
the normal GDB output. So that this problem can be solved properly.

Sincerely hope that any one can give me a hand. I am using MinGW.

Best regards,
Jingzhao

===========================================
(gdb)
&"shell dir\n"
Makefile             gdbmi_grammar.tab.o  gdbmi_pt.c         main.tcl
Makefile_orig        gdbmi_grammar.txt    gdbmi_pt.h         tkGDB.c
b                    gdbmi_grammar.y      gdbmi_pt.o         tkGDB.dll
bb                   gdbmi_lexer.l        lex.yy.c           tkGDB.exe
gdbmi_driver.c       gdbmi_parser.c       lex.yy.o           tkGDB_bak.c
gdbmi_grammar.tab.c  gdbmi_parser.h       libgdbmi_parser.a  tkGDB_stub.c
gdbmi_grammar.tab.h  gdbmi_parser.o       main.exe           tk_gdb.tcl
^done
(gdb)
===========================================

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

[Bob Rossi]

On Sat, Oct 08, 2005 at 10:19:33PM -0700, jingzhao.ou wrote:
> Dear all,
> 
> I am trying to see if it is possible to build a Tcl/Tk based GDB
> frontend using Bob Rossi's MI parser. For normal commands, it works
> just fine. However, if I execute "shell dir" command in gdb, the
> parser will report error. (see the end of the email)
> 
> I am wondering if there is any way to separate the shell output from
> the normal GDB output. So that this problem can be solved properly.
> 
> Sincerely hope that any one can give me a hand. I am using MinGW.
> 
> Best regards,
> Jingzhao
> 
> ===========================================
> (gdb)
> &"shell dir\n"
> Makefile             gdbmi_grammar.tab.o  gdbmi_pt.c         main.tcl
> Makefile_orig        gdbmi_grammar.txt    gdbmi_pt.h         tkGDB.c
> b                    gdbmi_grammar.y      gdbmi_pt.o         tkGDB.dll
> bb                   gdbmi_lexer.l        lex.yy.c           tkGDB.exe
> gdbmi_driver.c       gdbmi_parser.c       lex.yy.o           tkGDB_bak.c
> gdbmi_grammar.tab.c  gdbmi_parser.h       libgdbmi_parser.a  tkGDB_stub.c
> gdbmi_grammar.tab.h  gdbmi_parser.o       main.exe           tk_gdb.tcl
> ^done
> (gdb)
> ===========================================

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.

Thanks,
Bob Rossi

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

[jingzhao.ou]

Thanks a lot for the reply. I really like your idea if it can be
supported on both Windows and Linux platforms.

I have another problem with MI. I want to provide a GDB console in my
application so that the user can work with GDB directly if needed.
However, if I enable the MI interpreter, the normal GDB output is
suppressed. I hope that two interpreters can work at the same time and
their outputs are directed to two different output file descriptors.
This would give me exactly what I want and all I need. :-)

Again, thanks!

Best regards,
Jingzhao

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.
>
> Thanks,
> Bob Rossi
>

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

[Daniel Jacobowitz]

On Sun, Oct 09, 2005 at 10:04:36AM -0700, jingzhao.ou wrote:
> I have another problem with MI. I want to provide a GDB console in my
> application so that the user can work with GDB directly if needed.
> However, if I enable the MI interpreter, the normal GDB output is
> suppressed. I hope that two interpreters can work at the same time and
> their outputs are directed to two different output file descriptors.
> This would give me exactly what I want and all I need. :-)

We're a long way from being able to have multiple interpreters active
at the same time.  I agree it would be a good feature to have, and I've
got other uses for it (in scripting).

For now, for a console, you can use -interpreter-exec and get things
more or less right.  You can find a lot more about this in the list
archives, e.g. Apple's console-quoted hack.

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

A simpler and more specific solution for this particular problem would
be to run "shell" through pipes and MI encapsulate its output, to
prevent it from playing with the user's terminal.  I think that's a
good idea anyway. Right now, you can probably use interactive commands
via shell, but I believe that most uses of it are for things like ls,
grep, or make.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

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

[Bob Rossi]

> > 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). Some of the
target's apparently write to STDOUT/STDERR, and that get's confused with
the MI output. Also, thing's like 'shell' and potentially other case's
get mixed in with the MI output. Finally, if we have several
interpreters going at the same time, we could have them all output to
there own descriptor.
   
Bob Rossi

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

[jingzhao.ou]

interpreter-exec can give me what I am looking for. However, its
output is mixed with the MI output and will confuse Bob's parser. :-(

interpreter-exec console "b main"
&"interpreter-exec console \"b main\"\n"
Breakpoint 1 at 0x4012e7: file gdbmi_driver.c, line 14.
^done
(gdb)

It seems that support of multiple file descriptors is a potential
solution for such problems.

Best regards,
Jingzhao

On 10/9/05, Daniel Jacobowitz <drow@false.org> wrote:
> For now, for a console, you can use -interpreter-exec and get things
> more or less right.  You can find a lot more about this in the list
> archives, e.g. Apple's console-quoted hack.

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

[Daniel Jacobowitz]

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

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

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

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

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

-- 
Daniel Jacobowitz
CodeSourcery, LLC

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

[Daniel Jacobowitz]

On Sun, Oct 09, 2005 at 11:47:20AM -0700, jingzhao.ou wrote:
> interpreter-exec can give me what I am looking for. However, its
> output is mixed with the MI output and will confuse Bob's parser. :-(
> 
> interpreter-exec console "b main"
> &"interpreter-exec console \"b main\"\n"
> Breakpoint 1 at 0x4012e7: file gdbmi_driver.c, line 14.
> ^done
> (gdb)
> 
> It seems that support of multiple file descriptors is a potential
> solution for such problems.

IIRC this is exactly what console-quoted was for.

Ideally, IMO, we should have the CLI as a true frontend rather than
interwoven with gdb.  I don't know if that's practical.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

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

[Bob Rossi]

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

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

[Daniel Jacobowitz]

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

Re[2]: Separating "shell dir" output from GDB/MI output

[Konstantin Karganov]

Hello Daniel,

DJ> Ideally, IMO, we should have the CLI as a true frontend rather than
DJ> interwoven with gdb.  I don't know if that's practical.
It would be practical at least from the point of view that GDB
developers and GDB-users will stand on the same side of
"MI-barricade".
It will give a better chance to fix all this misundesrtandings like
with phantom "@target-output" feature and refine MI specification and
implementation details.

-- 
Best regards,
 Konstantin                            mailto:kostik@ispras.ru

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

[Eli Zaretskii]

> Date: Sun, 9 Oct 2005 08:33:26 -0400
> From: Bob Rossi <bob@brasko.net>
> Cc: gdb@sources.redhat.com
> 
> 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?

dup works on Windows as it does on Posix platforms, but I'm not sure I
understand the other details of what you suggest.  Could you post a
pseudo-code description of what you have in mind?

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

[Eli Zaretskii]

> Date: Sun, 9 Oct 2005 13:12:26 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sources.redhat.com
> 
> A simpler and more specific solution for this particular problem would
> be to run "shell" through pipes and MI encapsulate its output, to
> prevent it from playing with the user's terminal.  I think that's a
> good idea anyway.

I agree.  We just need to be careful to use the portable routines,
like pexecute or popen/pclose, and then it will work everywhere.