Re: probing GDB for MI versions

[Bob Rossi <bob@brasko.net>]

On Wed, Oct 06, 2004 at 11:57:56AM +0200, Eli Zaretskii wrote:
> > Date: Tue, 5 Oct 2004 08:11:36 -0400
> > From: Bob Rossi <bob@brasko.net>
> > Cc: g@white, gdb@sources.redhat.com
> 
> [Could you please remove that "g@white" from the CC list?  It bounces,
> so I need to manually remove it, which is a pain, as I respond to too
> many mails daily to afford editing the headers.  If you need that for
> your purposes, please use Bcc.]

Yes, I'm sorry about that.

> > > I don't see any catch: the output of this specific command could be
> > > made very simple so that it will not need any parsing, just some
> > > trivial string matching or at most regexps.
> > 
> > IMHO, it doesn't matter how easy it is to parse the MI output, it should
> > be done algorithmically. Simple or complicated, the same MI output
> > parser that parses the entire MI output syntax should be capable of
> > parsing the command we are suggesting.
> 
> That's a given.  What I meant to say was that the output of this
> command could be so simple (e.g., a simple string with no structure)
> that every MI parser would understand that.  Thus no catch-22.

Unfortunately this topic is on two different threads. I feel badly that I
am wasting your time here with bad descriptions of the "catch-22". This
is to help make my opinion clear on why it is a "catch-22" and not
possible.

   The front end has parsers for different versions of GDB's MI protocol. 
   The parser for MI2 may not work for the MI3 protocol.
   The parser for the MI3 protocol may not work for the MI2 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?

For instance, if in MI3, the MI output syntax was changed to add a
label for each MI output command to tell the front end what type of
command is being transmitted, or if any incompatible change was added
to the output syntax, than the parser for MI2 and MI3 would not work
with each other.

In this case alone, the front end can not start up GDB with a specific
version of MI. It needs to get from GDB the versions of MI that it
supports, and then start it up in the highest compatible mode.

This is why there needs to be a non-MI command to figure out what MI
versions the current GDB supports. It is also why I am claiming that
there is a catch-22.

> > The goal is to find out what versions of MI GDB supports so that you can
> > start GDB up in the highest compatible mode. Right?
> > 
> > How can you start GDB up in MI mode to ask it for the MI versions it
> > supports? You don't know what MI modes it supports, so you can not start
> > it in MI mode. That's the catch 22.
> 
> Again, I see no catch.  Here's what I had in mind:
> 
>   foo$ gdb -interpreter=mi
>   [the starting blurb omitted]
>   (gdb) -mi-version
>   mi3
> 
> After this, the front end could either (1) quit GDB and restart it
> with a "-interpreter=mi2" (say) switch, or (2) modify its parsing to
> adapt to MI version 3.

If I am proven to be wrong above, then this would be fine with me.

Bob Rossi