Re: MI starting guide

[Bob Rossi <bob at brasko dot net>]

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