Re: probing GDB for MI versions

["Alain Magloire" <alain at qnx dot com>]

> 
> On Wed, Oct 06, 2004 at 12:50:34PM +0100, Dave Korn wrote:
> > > -----Original Message-----
> > > From: gdb-owner On Behalf Of Bob Rossi
> > > Sent: 06 October 2004 12:39
> > 
> > > 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?
> > 
> >   No, we can't.  As long as the output from the -mi-version MI command stays
> > in the same format, you can always parse that and determine which version to
> > use.  
> 
> Dave, you do not understand the problem at all. I do not appreciate your
> defininative answer, especially since it is incorrect.
> 
> The actual MI output syntax is capable of changing between MI versions.
> If the MI4 output syntax (grammar) has an incompatible change with MI3,
> then 
>    * the MI3 parser will not even be capable of parsing and building a 
>      parse tree for the MI4 protocol.
>    * the MI4 parser will not even be capable of parsing and building a
>      parse tree for the MI3 protocol.
> 
> It is not possible to understand the output of the command no matter how
> simple it is. If there is no parse tree, then there is no way to
> understand the output from GDB.
> 
> > Everything else can change.  You can start up with an utterly minimal,
> > unintelligent parser, that knows nothing except how to send a -mi-version
> > command and parse the output; that parser can then direct one of your
> > version-dependent parsers to take over.
> 
> I don't understand the concept of an "utterly minimal unintelligent parser". 
> That is rediculous. I am generating a parser from the grammar.
> 
> There absolutly needs to be a way for the front end to ask GDB what
> versions of the MI protocol it supports. 
> 
> There is no way the front end can ask GDB what protocols it supports if
> it needs to talk to it with an MI protocol. Understood?
> 

I'm not sure on your rationnale to reject Dave's proposition.  It seems
to me it is a perfectly valid alternative for a front-end to probe
gdb and do an educated guess on what the better version of MI it 
can support.

gdb --interpreter=mi executable
(gdb) 1-mi-level
1^done,value="1"

The front-end loads MI Parser level 1 and continue exchange with gdb.

The other approach that was suggested, seems also interresting;
asking gdb on the command line for the list of protocols.
This first pass probing will allow the front-end to make a good choice
also.


The first idea to keep on probing gdb :

$ gdb -i mi5 executable
Interpreter `mi45' unrecognized
# try a nother
$ gdb -i mi4 executable
Interpreter `mi4' unrecognized
$ gdb -i mi2 executable
Bingo !!!

seems cumbersone but should work.

The problem that I did not see you mention in any previous thread, is
when there is a bug fix !! for example:
-thread-list-ids, keep on crashing, the next version of gdb fixes
the problem, how will a front-end knows to not use "info threads" but
can now use "-thread-list-ids".  Andrew's answer to this was to look
at the gdb version and make an educated guess, but we know the problem
with this, many distrubution have mangle gdb --version


(Just came back from a 2 weeks break, so I may have missed some context).