GDB/MI snapshots between major release's

[Bob Rossi]

On Mon, Oct 04, 2004 at 12:24:39PM -0700, Jason Molenda wrote:
> On Mon, Oct 04, 2004 at 11:12:01AM -0700, Felix Lee wrote:
> > Bob Rossi <bob@brasko.net>:
> > > With the information I have now, here is the problem. A snapshot of GDB
> > > will say that it is at MI4, although, it is really at some
> > > developmental version.
> > 
> > does that ever happen? if gdb says it supports MI4 but it
> > doesn't really, then it's lying, and that's a bug. 
> 
> For what it's worth, Bob does have a point here.
> 
> When an incompatible change to MI is made, the version # is bumped.
> >From that point in time until the new MI version is "finalized",
> it's usually a free-for-all to add whatever changes you want into
> the new MI version.
> 
> I don't know if there's an official way of telling whether a
> particular MI version has been finalized -- personally, I think of
> the highest MI version as being the in-development one, which is
> subject to change.
> 
> I don't really agree with the problem Bob is pointing out,
> personally.  If I were writing a front end, I'd target the
> highest stable version I can rely on (these days that would
> be MI2), and use that.  Or if I didn't really need the changes
> in MI2, I'd target MI1.

Yes yes, of course I am going to try to target the highest protocol that
the current GDB supports. The first implementation I write will be MI2.
The whole point of this thread is basically to figure out from GDB what
the highest stable protocol of MI that it supports is, and use it. I
want to be able to determine this even if GDB is not an official
release, but just a CVS snapshot.

> I do see some legitimate problems that Bob is raising.
> 
>  1. I don't know of an official way to tell if an MI command set
>     has been finalized.  The policy I outlined above -- the highest
>     # MI command set is in development, until the version # is bumped --
>     is my own understanding, but it might be wrong.

I basically need from GDB all of the MI versions that it supports. This
list should not include a development version of the MI protocol, that
is currently being worked on. If you have a CVS snapshot you currently
have no way of knowing that the highest MI protocol number is a
development version, and not an official release.

>  2. There isn't any way for a front end developer to tell exactly
>     what the MI differences are without looking at the source.  I
>     know old gdb releases' documentation should make this clear,
>     but I'd be surprised if it's really clear enough to write an
>     implementation from.

This is true, I would already have a hard time write an MI protocol
implementation. I really think at least having the differences from the
last protocol would be a big help. At least that way, I could start with
MI3, and then when MI4 comes around, I could see a list of
incompatibilites. The real answer to me would be to have a list of all
the MI protocols documented in every release. Especially since they are
backwards compatible, and GDB still supports them. Maybe things like
have the MI commands list what version of MI they appeared in.

>  3. Is there a guarantee that old MI interfaces will be supported?
>     Or will we wake up to find gdb 6.3 has deprecated, e.g. MI1, and
>     scheduled it for purging?

This is what I need to know.

Thanks,
Bob Rossi