Re: MI -break-info command issues

[Eli Zaretskii <eliz@gnu.org>]

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

I will personally applaud anyone who submits improvements to the MI
docs.

> 2. Looking at 'mi-read-memory.exp', those fields don't appear to be tested
> -- it's only checked that the values of the fields are in hex.

I'm sure we will happily accept patches to the test suite as well.

> 3. Everybody using MI should decide if those fields are useful for him, or
> not.

If you have ideas how to improve this aspect (without hurting
generality), please consider sharing them.

> The problem with existing frontends can probably be solved by posting a
> prominent message to mailing list whenever MI output is going to change. Or
> using versioning.

The latter possibility was discussed in some length several months
ago, and I think we have now a mechanism to do this.