Re: MI -break-info command issues

[Bob Rossi <bob at brasko dot net>]

On Fri, Jan 27, 2006 at 07:10:54PM +0200, Eli Zaretskii wrote:
> > From:  Vladimir Prus <ghost@cs.msu.su>
> > Date:  Fri, 27 Jan 2006 18:47:47 +0300
> > 
> > > _Extending_ MI is fine; it was designed to be extensible.  _Removing_
> > > fields from MI is not fine, because you don't know if some other
> > > frontend relies on the data that you find superfluous.
> > > 
> > > Folks have said this at least twice in this thread already.  If you
> > > disagree, could you say why?
> > 
> > Because with those fields, you get new issues:
> > 
> > 1. They are not documented in sufficient detail.
> 
> The truth is, _nothing_ in GDB/MI is documented in sufficient detail.
> We are lucky to have any documentation at all.
> 
> Historically, GDB/MI was added to the sources without _any_
> documentation.  I needed to lobby those who wrote the code to make
> some docs available, and finally got a kind of white paper that
> described what MI _will_ look like; it goes without saying that the
> reality was quite different.  I then needed to edit that document
> heavily to make it fit into the manual (convert chapters to sections,
> sections to subsections, fix style and Texinfo usage, etc.) and that
> is what we have now, basically, except that some portions were
> improved since then, whenever commands were added/changed.

Eli, one thought I had recently was this. I would like to automate the
examples, using the testsuite. So that if an MI output command changed,
the sample would be updated. Do you think this would be possible to do?

I find the documentation get's quickly out of date with what GDB is
actually outputting. We could add a new test case, which would get the
mi output commands we are interested in, and put them in the tex file
somehow. What do you think? Sounds ambitious, I know.

Bob Rossi