How about remote MI?

How about remote MI?

[teawater]

Hi all,


In May, I release GDBRUI(http://sourceforge.net/projects/gdbrui/) that
is an interpreter to make GDB can be controlled by the other programe
through TCP. But some people ask me why not extend MI to support TCP.
Now, I think this idea is cool. Does GDB MI support TCP? Maybe I can
extend MI to support TCP. How do you think about it?

BTW, I am trying to make vim2gdb (An vim plug-in to make vim can debug
code through GDB. It use GDBRUI in before.) support MI. But the MI
output format is not very easy to parse. Could some people recommend a
programe or example that parse the MI output for me? If not, I think I
will use lex to parse it.


Thanks,
teawater

Re: How about remote MI?

[Nick Roberts]

 > In May, I release GDBRUI(http://sourceforge.net/projects/gdbrui/) that
 > is an interpreter to make GDB can be controlled by the other programe
 > through TCP. But some people ask me why not extend MI to support TCP.
 > Now, I think this idea is cool. Does GDB MI support TCP? Maybe I can
 > extend MI to support TCP. How do you think about it?

gdbserver supports TCP.  You can control a remote program using MI and
gdbserver.  MI is a formal interface for use by front ends.  I'm not sure that
gdbrui, as you describe it, fills the same role

 > BTW, I am trying to make vim2gdb (An vim plug-in to make vim can debug
 > code through GDB. It use GDBRUI in before.) support MI. But the MI
 > output format is not very easy to parse. Could some people recommend a
 > programe or example that parse the MI output for me? If not, I think I
 > will use lex to parse it.

I think the idea is that the front end parses it directly.  Generating an
intermediate langusage just adds to the complexity.  If you think MI can
be improved then please make suggestions.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: How about remote MI?

[teawater]

On 7/15/06, Nick Roberts <nickrob@snap.net.nz> wrote:
>  > In May, I release GDBRUI(http://sourceforge.net/projects/gdbrui/) that
>  > is an interpreter to make GDB can be controlled by the other programe
>  > through TCP. But some people ask me why not extend MI to support TCP.
>  > Now, I think this idea is cool. Does GDB MI support TCP? Maybe I can
>  > extend MI to support TCP. How do you think about it?
>
> gdbserver supports TCP.  You can control a remote program using MI and
> gdbserver.  MI is a formal interface for use by front ends.  I'm not sure that
> gdbrui, as you describe it, fills the same role
>

MI is an interpreter.
GDBRUI is an interpreter too.
interps.c

>  > BTW, I am trying to make vim2gdb (An vim plug-in to make vim can debug
>  > code through GDB. It use GDBRUI in before.) support MI. But the MI
>  > output format is not very easy to parse. Could some people recommend a
>  > programe or example that parse the MI output for me? If not, I think I
>  > will use lex to parse it.
>
> I think the idea is that the front end parses it directly.  Generating an
> intermediate langusage just adds to the complexity.  If you think MI can
> be improved then please make suggestions.

My means is that I need parse MI output in other programe.

>
>
> --
> Nick                                           http://www.inet.net.nz/~nickrob
>

Re: How about remote MI?

[Nick Roberts]

 > > gdbserver supports TCP.  You can control a remote program using MI and
 > > gdbserver.  MI is a formal interface for use by front ends.  I'm not sure
 > > that gdbrui, as you describe it, fills the same role
 > >
 > 
 > MI is an interpreter.
 > GDBRUI is an interpreter too.
 > interps.c

TUI is an interpreter too, but it's not a machine interface like MI.  I think
you have said that with GDBRUI the user still interacts with the command line
which makes it sound more like TUI.  You may have done something brilliant and
single handedly written an interface that is better than MI, but you don't
currently have mind share.  I think if we are to follow what you have done,
and what you want to achieve, you have to take things in smaller steps.  What
advantages does GDBRUI have over MI?  One or two simple examples would be good
to start with.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: How about remote MI?

[teawater]

GDBRUI(http://sourceforge.net/projects/gdbrui/) is not like TUI. I
think It like MI. MI support a PIPE interface. GDBRUI support a TCP/IP
interface to other program. So the program that is in another machine
can control GDB via TCP/IP.
So I think maybe I can do some work to make MI support TCP/IP
interface. How do you think about it?

On 7/16/06, Nick Roberts <nickrob@snap.net.nz> wrote:
>  > > gdbserver supports TCP.  You can control a remote program using MI and
>  > > gdbserver.  MI is a formal interface for use by front ends.  I'm not sure
>  > > that gdbrui, as you describe it, fills the same role
>  > >
>  >
>  > MI is an interpreter.
>  > GDBRUI is an interpreter too.
>  > interps.c
>
> TUI is an interpreter too, but it's not a machine interface like MI.  I think
> you have said that with GDBRUI the user still interacts with the command line
> which makes it sound more like TUI.  You may have done something brilliant and
> single handedly written an interface that is better than MI, but you don't
> currently have mind share.  I think if we are to follow what you have done,
> and what you want to achieve, you have to take things in smaller steps.  What
> advantages does GDBRUI have over MI?  One or two simple examples would be good
> to start with.
>
>
> --
> Nick                                           http://www.inet.net.nz/~nickrob
>

Re: How about remote MI?

[Nick Roberts]

 > GDBRUI(http://sourceforge.net/projects/gdbrui/) is not like TUI. I
 > think It like MI. MI support a PIPE interface. 

I thought it used a terminal just as with CLI.  I see no reference to pipes
in the MI section of the manual.

 > GDBRUI support a TCP/IP
 > interface to other program. So the program that is in another machine
 > can control GDB via TCP/IP.
 > So I think maybe I can do some work to make MI support TCP/IP
 > interface. How do you think about it?

I don't see the point, so you'll have to see what Daniel J says.  Maybe he
will understand.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: How about remote MI?

[Bob Rossi]

>  > BTW, I am trying to make vim2gdb (An vim plug-in to make vim can debug
>  > code through GDB. It use GDBRUI in before.) support MI. But the MI
>  > output format is not very easy to parse. Could some people recommend a
>  > programe or example that parse the MI output for me? If not, I think I
>  > will use lex to parse it.
> 
> I think the idea is that the front end parses it directly.  Generating an
> intermediate langusage just adds to the complexity.  If you think MI can
> be improved then please make suggestions.

This is simply not true. It is possible to write an MI parser that "works".
However, AFAIK, no one (besides maybe eclispse) has written a production 
quality MI parser that works under all cicumstances, is well tested, ...

Having everyone use there own parser is a lose-lose situation. It will
add to the MI maintaince burden with loads of questions per developer,
it will waste every projects time that wants a parser, and it will give
the community at large a bad sense of GDB front ends (which it already
has BTW) because each not fully tested MI parser will fail in slightly
different boundry cases.

I have started an effort here to provide an MI parser. It is far from
complete. It is not well tested. It does not have documentation.
However, it does syntacticaly parse the output of the test suite.

svn co https://svn.sourceforge.net/svnroot/cgdb/cgdb/trunk/lib/gdbmi
gdbmi

Sometime in the future I will get more time and will eventually get
this silly parser complete. At this point, you can use it to get an AST
of the MI, which is still very useful.

Thanks,
Bob Rossi

Re: How about remote MI?

[Daniel Jacobowitz]

On Sat, Jul 15, 2006 at 09:50:54PM +0800, teawater wrote:
> Hi all,
> 
> 
> In May, I release GDBRUI(http://sourceforge.net/projects/gdbrui/) that
> is an interpreter to make GDB can be controlled by the other programe
> through TCP. But some people ask me why not extend MI to support TCP.
> Now, I think this idea is cool. Does GDB MI support TCP? Maybe I can
> extend MI to support TCP. How do you think about it?

I do not see the point.  GDB/MI talks to a terminal or a pipe.  If you
want to connect that pipe to a TCP socket, GDB doesn't need to know
that it's a socket.

You can use netcat to connect an arbitrary process to a bidirectional TCP
socket.  There's a bunch of other similar tools, too.

-- 
Daniel Jacobowitz
CodeSourcery

Re: How about remote MI?

[teawater]

Agree with you.

Thanks,
teawater

On 7/17/06, Daniel Jacobowitz <drow@false.org> wrote:
> On Sat, Jul 15, 2006 at 09:50:54PM +0800, teawater wrote:
> > Hi all,
> >
> >
> > In May, I release GDBRUI(http://sourceforge.net/projects/gdbrui/) that
> > is an interpreter to make GDB can be controlled by the other programe
> > through TCP. But some people ask me why not extend MI to support TCP.
> > Now, I think this idea is cool. Does GDB MI support TCP? Maybe I can
> > extend MI to support TCP. How do you think about it?
>
> I do not see the point.  GDB/MI talks to a terminal or a pipe.  If you
> want to connect that pipe to a TCP socket, GDB doesn't need to know
> that it's a socket.
>
> You can use netcat to connect an arbitrary process to a bidirectional TCP
> socket.  There's a bunch of other similar tools, too.
>
> --
> Daniel Jacobowitz
> CodeSourcery
>

Re: How about remote MI?

[Bob Rossi]

On Sun, Jul 16, 2006 at 08:57:20PM -0400, Daniel Jacobowitz wrote:
> On Sat, Jul 15, 2006 at 09:50:54PM +0800, teawater wrote:
> > Hi all,
> > 
> > 
> > In May, I release GDBRUI(http://sourceforge.net/projects/gdbrui/) that
> > is an interpreter to make GDB can be controlled by the other programe
> > through TCP. But some people ask me why not extend MI to support TCP.
> > Now, I think this idea is cool. Does GDB MI support TCP? Maybe I can
> > extend MI to support TCP. How do you think about it?
> 
> I do not see the point.  GDB/MI talks to a terminal or a pipe.  If you
> want to connect that pipe to a TCP socket, GDB doesn't need to know
> that it's a socket.
> 
> You can use netcat to connect an arbitrary process to a bidirectional TCP
> socket.  There's a bunch of other similar tools, too.

There ia at least one possibility I can think of that would improve 
upon GDB/MI by having it connect back to the FE via a TCP socket.

That is, it would avoid the 'tty' issue, by allowing the FE to put a
single pty between the FE and GDB, and having all the MI protocol 
on a totally separate channel.

Bob Rossi

Re: How about remote MI?

[Daniel Jacobowitz]

On Mon, Jul 17, 2006 at 09:27:10AM -0400, Bob Rossi wrote:
> There ia at least one possibility I can think of that would improve 
> upon GDB/MI by having it connect back to the FE via a TCP socket.
> 
> That is, it would avoid the 'tty' issue, by allowing the FE to put a
> single pty between the FE and GDB, and having all the MI protocol 
> on a totally separate channel.

I don't see any advantage over using the "set tty" command now that
we've got it...

-- 
Daniel Jacobowitz
CodeSourcery

Re: How about remote MI?

[Bob Rossi]

On Mon, Jul 17, 2006 at 09:43:20AM -0400, Daniel Jacobowitz wrote:
> On Mon, Jul 17, 2006 at 09:27:10AM -0400, Bob Rossi wrote:
> > There ia at least one possibility I can think of that would improve 
> > upon GDB/MI by having it connect back to the FE via a TCP socket.
> > 
> > That is, it would avoid the 'tty' issue, by allowing the FE to put a
> > single pty between the FE and GDB, and having all the MI protocol 
> > on a totally separate channel.
> 
> I don't see any advantage over using the "set tty" command now that
> we've got it...

OK, the overhead of TCP would be pretty high just to solve that problem.
However, there is a slight problem, and I've made it clear in past
threads. That is, if a front end uses 'set tty' it doesn't know exactly
which process to send signals to.

Yes, this is a minor problem, and I haven't had significant issues with
it yet.

Bob Rossi