Re: GDB/MI snapshots between major release's

Jason Molenda
2004-10-04T19:24:40Z

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.

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.

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.

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?

Realistically, the changes to MI are not dramatic; they're almost
always additions that can be ignored if the front end wasn't expecting
them -- that was the whole point of the MI output design. The most
obvious break was mi0 vs mi1, but that was a long time ago.

On the other hand, the reason the MI interface has been so stable is
(IMHO) because there are so few shipping FEs that use it. Apple has
one, and we've got quite a large number of changes in the MI. I
understand Eclipse is now using it -- the resurgance of work on the
FSF gdb MI interface these past couple years is the evidence of that.
As more FEs start using MI, I expect there to be more changes, or
at least more requests for changes, to the protocol. And so these
sorts of issues could legitimately be important to set down.

Jason