Re: probing GDB for MI versions

["Alain Magloire" <alain@qnx.com>]

> 
> On Thu, Oct 07, 2004 at 03:50:18PM +0100, Dave Korn wrote:
> > > -----Original Message-----
> > > From: 'Bob Rossi'
> > > Sent: 07 October 2004 15:37
> > 
> > > I understand that adding an MI command to the MI function set that can
> > > not be accessed by a front end that understands the MI protocol is
> > > nonsensical and confusing
> > 
> >   Since nobody has proposed such an addition, your opinion of it is utterly
> > irrelevant.
> 
> Again, you do not understand the issue. 
> 
> Adding this new function -mi-version, will be adding the first command 
> to the MI command set that is supposed to be used by a front end by 
> *not* using an MI protocol. It is confusing and non-sensical to add the
> first MI command to the MI command set that can not be used by a front 
> end that speaks the MI protocol.
> 

(I have this funny feeling, that you guys are going in circle !
 Am I missing an important piece of the puzzle ?)

Bob, I thought I was following your way of thinking but you lost me there.
One of the reason(correct me If I'm wrong) to add -mi-version is if
the front-end start gdb like this
$ gdb -i=mi executable

Doing "-mi-version" will let the front-end adjust which parser to instanciate.

But after that, you seem to get lost on implementation details, chicken and egg
problem, with reasoning like: we need to parse the "-mi-version" with an MI parser
but wait ... we can not start the parser since we do not know yet which parser to
instanciate.

Davek's point(which I tend to agree with) is saying you need to bootstap somehow.

Let's focus for a second on this issue, from the 3 scenarios below which one
will be satisfactory for you:

1- front end starts gdb with different mi version until it finds a good one
    $gdb -i=mi4  # fails
    $gdb -i=mi3  # fails
    $gdb -i=mi2  # sucess, start debuging

2- front end choose the protocol form the list of known
   $gdb --list-protocols
   
3- the -mi-version


(1) looks allright and no changes is needed
(2) could be nicer
(3) is ok.