Re: GDB/MI snapshots between major release's

["Eli Zaretskii" <eliz at gnu dot org>]

> Date: Wed, 6 Oct 2004 07:27:03 -0400
> From: Bob Rossi <bob@brasko.net>
> Cc: Daniel Jacobowitz <drow@false.org>, gdb@sources.redhat.com
> 
> > 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

In general, it won't, but for a very specific case of _a_single_command_,
it could very well do.  Obviously, we will need to agree to _never_ 
change the syntax of the output of that command once it is introduced,
but that is all we need to do to make sure _every_ MI parser henceforth
will understand that command's output.

> 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?

Obviously, I disagree: if the syntax of what that command outputs does
not change, you should be able to use _any_ MI parser that knows about
this command; in particularly, the latest MI parser will do, so
invoking GDB with "-interpreter=mi" will solve the problem.  Can we
agree on this point?

> > > 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.

So how these front ends solve this problem now?

> > 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.

I still don't see the problem, sorry.  Your front end surely knows (or
can know) what is the latest MI version it supports, right?  If so,
the following simple algorithm should do what you want:

  get the latest stable MI version from GDB, call it $mi-ver
  if $mi-ver is greater than N, the latest MI version supported by the front-end
    then restart GDB with "-interpreter=miN"
    else either set up to use the parser for $mi-ver
         or restart GDB with "-interpreter=mi"
  endif

What am I missing?

> 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.

If that happens, invoking GDB with "-interpreter=mi2" will exit with a
failure status and print an error message.  That should be enough for
the front end to say that it cannot work with such a GDB, if MI2 is
the only MI version the front end understands.  Still no problem that
I see; do you?