Re: GDB/MI snapshots between major release's

[Bob Rossi <bob at brasko dot net>]

On Wed, Oct 06, 2004 at 12:15:40PM +0200, Eli Zaretskii wrote:
> > Date: Tue, 5 Oct 2004 10:07:36 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Bob Rossi <bob@brasko.net>, kettenis@gnu.org, gdb@sources.redhat.com
> > 
> > I think using a command line switch makes sense.  You're going to have
> > to restart GDB to change MI protocols anyway, so why force the user to
> > go into MI?
> 
> First, it is possible that when the front end knows which MI version
> is the last stable one, it will not need to restart GDB, but just
> arrange for the appropriate parser to be used for the rest of the
> session.

This is not correct. The front end has parsers for different versions of
GDB's MI protocol. The parser for MI2 will not work for the MI3 protocol
The front end *can not* start up GDB just by using -interpreter=mi
because it doesn't know what parser to use in this situation.
Can we agree on this point for starters?

This is why there needs to be a non-MI command to figure out what MI
versions the current GDB supports.

> A downside of the command-line option that I very much don't like is
> that command-line options are mainly for the human users and are
> documented in a special section that describes how to run GDB, not how
> to use the MI interpreter.

Yes, this is a downside, but I don't think your MI solution is quite
ready for use, however, maybe we could come up with something better
still.

> > I also like the idea of listing non-MI (which right now means annotate)
> > protocols in the same output.
> 
> Does some front end need that?  If not, why introduce unneeded
> generalizations?  

Yes, of course they do :)
xxgdb, ddd, gvd, ...
They all use annotations and they all assume annotate 1 is around. As
soon as you pull annotate 1, they will all have the same problem.

Emacs uses annotate 1, probably annotate 2 at some version and now
annotate 3 at some version. Also, I believe it's moving into the MI
realm .... what a mess ...

> I actually think that the output of the feature we
> are discussing needs to be a single string: the latest version of MI
> supported by this GDB that is known to be stable.  Given that info,
> the front end should be able to figure out all the stable versions it
> can use: they are those whose version numbers are below the latest
> stable one.

This is wrong. I *need* the output to have *all* the versions of MI that
the current GDB supports. I need this for a very very simple reason. I
need to make sure that my front ends that don't support the current
official release of GDB can start GDB in the highest mode it supports.

If at some point, GDB decides not to honor MI2 anymore, I need to make
sure that I know that. If my front end only supports MI2, and GDB
supports only MI3, than the function you are suggesting will not be good
enough for me.

Bob Rossi