MI starting guide

MI starting guide

[Bhanu Nagendra Pisupati]

Hello,
I have looked around for documentation to help me get started with using
the GDB/MI interface. I found material that described the interface in
general (command interface/ usage scenarios etc), but failed to address
some basic questions (that might have been considered trivial). For one,
how does a user process wanting to interact with GDB using the MI do so
(pipes?). Any 'hello world' document that walks me through a basic session
would be greatly useful. Please let me know if there is one I can refer
to.
Thanks,
-Bhanu

Re: MI starting guide

[Bob Rossi]

On Fri, Mar 11, 2005 at 06:48:27PM -0500, Bhanu Nagendra Pisupati wrote:
> Hello,
> I have looked around for documentation to help me get started with using
> the GDB/MI interface. I found material that described the interface in
> general (command interface/ usage scenarios etc), but failed to address
> some basic questions (that might have been considered trivial). For one,
> how does a user process wanting to interact with GDB using the MI do so
> (pipes?). Any 'hello world' document that walks me through a basic session
> would be greatly useful. Please let me know if there is one I can refer
> to.

There is no user document that I know of that describes how to write an
FE on top of GDB using the MI interface besides the manual. 

AFAIK, FE's use fork/exec with GDB and communicate with it over a pipe
like you suggested. Beware, some of the MI commands that the manual says
are there are unimplemented.

If you want to see some interaction between GDB and another process look
at the gdb.mi testsuite.

Bob Rossi

Re: MI starting guide

[Eli Zaretskii]

> Date: Fri, 11 Mar 2005 19:04:37 -0500
> From: Bob Rossi <bob@brasko.net>
> Cc: gdb@sources.redhat.com
> 
> There is no user document that I know of that describes how to write an
> FE on top of GDB using the MI interface besides the manual. 

Sad, but true.

Actually, the MI documentation in the manual was once a separate
manual which was not compiled into gdb.info.  I did some minimal work
to integrate it into gdb.texinfo (because I believe that some
documentation is better than no documentation), but I won't pretend
that the result is in good shape, and I don't know enough about MI to
improve those parts of the manual in useful ways.

> AFAIK, FE's use fork/exec with GDB and communicate with it over a pipe
> like you suggested. Beware, some of the MI commands that the manual says
> are there are unimplemented.
> 
> If you want to see some interaction between GDB and another process look
> at the gdb.mi testsuite.

I'm urging people who work with the MI interface, such as Nick and
Bob, to please contribute additions to the manual (either gdb.texinfo
or gdbint.texinfo) that describe what you found out during your work
that you wish has been there to begin with.  There is no better source
of useful information than those who actually need it to do some job.

If you are unsure how or where best to describe what you think is
important, don't hesitate to post your thoughts here and start a
discussion.

TIA

Re: MI starting guide

[Bob Rossi]

> > AFAIK, FE's use fork/exec with GDB and communicate with it over a pipe
> > like you suggested. Beware, some of the MI commands that the manual says
> > are there are unimplemented.
> > 
> > If you want to see some interaction between GDB and another process look
> > at the gdb.mi testsuite.
> 
> I'm urging people who work with the MI interface, such as Nick and
> Bob, to please contribute additions to the manual (either gdb.texinfo
> or gdbint.texinfo) that describe what you found out during your work
> that you wish has been there to begin with.  There is no better source
> of useful information than those who actually need it to do some job.
> 
> If you are unsure how or where best to describe what you think is
> important, don't hesitate to post your thoughts here and start a
> discussion.

Thanks to all who originally contributed to the GDB doco, that's why we
are even able to talk about this!

Honestly Eli, there are so many improvements that we could add, the sky
is the limit. In fact, I have several ideas of improving the MI
interface doco, of course, none of this will get done if the patch review
time issue isn't resolved.

   - obviously a section on 'asycnronous' MI interface, which I still
     don't understand the purpose of (since I can't get any of the
     asynchronous commands to work)
   - make sure that the documented "example" commands section stay up
     to date with what GDB actually outputs. I have a funny feeling that
     many of the commands do not actually output the same info anymore.
     (we could generate the example data from a testsuite case, and diff
     what GDB currently outputs to what it is supposed to output to
     make sure the data doesn't change)
   - Document what MI commands are implemented/unimplemented
   - Document the correct MI output command grammar (which is almost
     correct, but not really)
   - Somehow document what versions each command was introduced in
   - A developers howto guide (Although, I think the reference
     implementation I was talking about would be a better way to
     describe this)
   - Document what MI fields are mandatory output for a command, and
     which ones are optional.

I know all of this is a lot of work, but as we move on, I think it would
improve the state of affairs a lot. As far as a developers user guide, if
GDB had a reference implementation, which I would like to work on, there
could be a design guide that goes along with it. This would basically be
essential anyways, if my goal of making GDB scriptable via the MI
interface is ever going to happen.

Personally, I've said this from the beginning. I really don't think
anyone should start from scratch, writing an FE on top of GDB/MI. I
think GDB should provide a parser, capable of parsing an MI output
command, and also an interface to understand the semantics of that parse
tree. GDB is the only one who can provide such an interface, and ensure
that it is tested in the testsuite, to provide FE's with a quality
interface to working with it.

Bob Rossi

Re: MI starting guide

[Eli Zaretskii]

> Date: Sat, 12 Mar 2005 09:40:54 -0500
> From: Bob Rossi <bob@brasko.net>
> Cc: bpisupat@cs.indiana.edu, gdb@sources.redhat.com
> 
> Honestly Eli, there are so many improvements that we could add, the sky
> is the limit. In fact, I have several ideas of improving the MI
> interface doco, of course, none of this will get done if the patch review
> time issue isn't resolved.

There's no need to wait for the patch review issue to get resolved.
Since I'm the area maintainer for the documentation, I can approve
doco patches myself.  And I usually review such patches the moment I
read them.

>    - obviously a section on 'asycnronous' MI interface, which I still
>      don't understand the purpose of (since I can't get any of the
>      asynchronous commands to work)
>    - make sure that the documented "example" commands section stay up
>      to date with what GDB actually outputs. I have a funny feeling that
>      many of the commands do not actually output the same info anymore.
>      (we could generate the example data from a testsuite case, and diff
>      what GDB currently outputs to what it is supposed to output to
>      make sure the data doesn't change)
>    - Document what MI commands are implemented/unimplemented
>    - Document the correct MI output command grammar (which is almost
>      correct, but not really)
>    - Somehow document what versions each command was introduced in
>    - A developers howto guide (Although, I think the reference
>      implementation I was talking about would be a better way to
>      describe this)
>    - Document what MI fields are mandatory output for a command, and
>      which ones are optional.

These are all good ideas, so feel free.  I suggest to pick up some
aspect of MI that you know best, or that doesn't require a too deep
knowledge of the implementation (e.g., the implemented/unimplemented
thing), and start with that.