Re: GDB/MI snapshots between major release's

[Bob Rossi <bob@brasko.net>]

On Wed, Oct 06, 2004 at 02:26:55PM +0200, Eli Zaretskii wrote:
> > 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.  

You obviously not understanding the point here. I can not even get my
front end to the point where it can look at the command. The reason is,
I can not *PARSE* the command. 

Here is a simple explanation that I have tried to discuss over and over.
   
   1. Each version of MI comes with a grammar.
   2. If the MI grammar changes between MI1 and MI2 then
   3. A parser is generated that understands the grammar for MI1
   4. A parser is generated that understands the grammar for MI2
   5. The parser for MI1 *will not parse* the output of MI2
   6. The parser for MI2 *will not parse* the output of MI1

Therefor, I don't have a parse tree, and can not even begin to
understand what MI output command GDB just sent to me. There is no
"specific case", where a front end could understand
"_a_single_command_".

This is a very simple issue I am discussing here and I expect people to
understand what I am saying.

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

You are ready to guarentee that the MI output syntax (grammar) will
never change? This has nothing to do with the way the MI output command
lists the versions (field names, ... ).

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

Are you saying that the MI output syntax wil never change? I doubt you
can make this promise.

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

They assume annotate 1 is there, since it's 10 years old or so.
If it's not there, you probably will get random results.

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

You are missing elegance. It is a "first approach" to start GDB in every
MI mode from the highest one that the front end supports down. It would
be much more elegant to just ask GDB what versions of MI it supported.
As front ends scale, it could have to start GDB 10 times to figure out
what MI protocol it supports, even then, you wouldn't know if it was a
development protocol or not.

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

I understand your point here. I still think if we are going to put the
last officially released version, it would just be nice and easy to put
them all.

Thanks,
Bob Rossi