This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI -break-info command issues
On Fri, Jan 27, 2006 at 06:47:47PM +0300, Vladimir Prus wrote:
> > On Fri, Jan 27, 2006 at 05:59:56PM +0300, Vladimir Prus wrote:
> >> If "minimal" protocol is explicitly not a goal of MI, or changing MI is
> >> prohibited, just say so and I'll stop asking why there are unnecessary
> >> fields.
> >
> > _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.
> 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.
> 3. Everybody using MI should decide if those fields are useful for him, or
> not.
I don't buy it. If you don't know for sure what they do, and you don't
need them, just ignore them - MI is designed to make unknown fields
easy to ignore.
> 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.
This has been discussed before plenty of times. We will make
incompatible changes to MI from time to time; but IMO that doesn't
justify making _unnecessary_ incompatible changes.
Like Bob, I wouldn't have added the fields. But since they are
present, I see no reason to remove them.
--
Daniel Jacobowitz
CodeSourcery