Re: probing GDB for MI versions

['Bob Rossi' <bob@brasko.net>]

On Thu, Oct 07, 2004 at 12:14:00PM -0400, Alain Magloire wrote:
> > 
> > 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.

Yes, asking GDB what version is supports allows the front end to chose a
parser that can handle the MI protocol.

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

Yes.

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

Yes, you need to bootstrap, I agree.

> 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

This is possible, yet is obviously ugly. Imagine MI 1000 :)
Also, GDB starts up it's development version of MI when you ask it to.

> 2- front end choose the protocol form the list of known
>    $gdb --list-protocols

I like this solution. 
However, I understand that not everyone does and I can see why.

> 3- the -mi-version

I do not like this solution. I do not like adding an MI command to the
MI function set that is not intended to be parsed by a front end that
can speak the MI protocol. I've stated that this is confusing and
nonsensical.

I understand that the new mi command could be called by a front end that
speaks the MI protocol, but only after the front end new which MI
protocol to speak. The front end would have to come up with an adhoc
parser for getting the information that it needs, and this would be the
first and only MI command that has to be used like this.

Finally, there are several other solutions,

   * An interpreter that only outputs the mi versions
   * A handshaking protocol 
   * Have GDB output it's last stable version of MI as the first thing
     it outputs (subset of case above)

Thanks,
Bob Rossi

Thanks,
Bob Rossi