Re: [rfa:doco] Zap mi1 reference

[Bob Rossi <bob@brasko.net>]

On Mon, Feb 16, 2004 at 06:27:14PM -0500, Andrew Cagney wrote:
> >On Fri, Feb 13, 2004 at 03:05:06PM -0500, Andrew Cagney wrote:
> >
> >>Hello,
> >>
> >>This removes a reference to "mi1" in the documentation.  It's no longer 
> >>tested (hence 'supported').
> >
> >I think the MI functions should be backwards compatible. Are they?
> 
> Theory or reality?  In theory the output is largely upward compatible - 
> code can discard unrecognized fields.  In reality warts eventually start 
> to appear.  For instance, both:

In reality, I don't think front end writers will want to continually
depend on writing new MI interface layers in order to keep compatibility
with GDB.

As a front end writer, and as being interested in writing a thin layer
on top of MI, I am concerned with backwards compatibility.

I wrote an annotate-2 module that plugs into libtgdb. I wrote it using
gdb.5.3, however, it seems to work perfectly with versions of gdb as old
as 4.x. I am interested in seeing the same compatibility with MI.

If I was to write an MI module for libtgdb, do you see that working for
only gdb 6.0? Would I then have to write a MI2 module for 6.1? I would
hope that my MI1 library would work with both GDB 6.0,6.1. Is this a
quality the MI protocol is going to sustain? and that an MI2 module
would only allow for more functionality, or more of something.

> - using frame ID's with varobj
> - N:M breakpoints
> will impact significantly on the MI interface.

Will this break all MI1 front end clients?

Bob Rossi