Re: probing GDB for MI versions

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

> I was only talking about stable versions, so developmental is not
> something we should consider (we've been through this and decided that
> it is unsafe to use such versions).

Yes, you are correct.

> > This information needs to be given to the front end. For
> > example, right now GDB supports MI2. However, if a front end understood
> > only MI1, then it would be tempted to try MI1 with your approach.
> > However, MI1 is unsupported and most likely doesn't work.
> 
> If MI1 is not working and the front end only supports MI1, then this
> combination of GDB and front end is not going to work.  So I submit
> that this case is not interesting: you will try MI1 and things will go
> wrong at some point.
> 
> However, ``unsupported'' and ``doesn't work'' are not the same thing.
> If we know that a certain version of MI does not work, we should
> remove its support from GDB.  If we didn't do that, then we have good
> reasons to believe that MI1 does in fact work.

I think that supported(tested) and unsupported(untested) are two
entirely different things. Users should not be responsible for finding
bugs in the MI protocol because GDB said that a front end could use a
depricated protocol. It's just not fair. Also, above and beyond that, I
do not want my front end to work with untested versions of the MI
protocol, it would simply make me look bad when things stopped working
half way throuh a session.

> > It would be
> > nice if the front end was capable of understanding that.
> 
> And then do what? print a message "like unsupported GDB version"?  Is
> this really an interesting case?  

I consider this a very interesting case.

> I thought you were interested in
> getting a front end to _work_ with MI; graceful failure is something
> different.  Can we please solve one problem at a time?  Do you agree
> that if either (1) the front end supports the latest stable version or
> (2) the version before that works reasonably well, then printing only
> the latest stable version at startup is good enough?

No, I can not agree to that. Again, like I said to andrew, printing the
latest stable version simply is common sense. It allows the front end to
determine if it can work with the current GDB. It is a different problem
than probing GDB to determine what MI versions that it supports.

Especially the second case that you have posted makes no sense to me,
"the version before works reasonably well". I don't want a reasonably
well working verion, I want a version that it tested in the testsuite.

> > This seems reasonable. There are 2 down sides that I don't like
> > 
> >    * There is no handshaking being done. Average case scenario is starting
> >      GDB twice to get it into the correct mode. Once to find out the
> >      supported versions, second to start it in the correct mode.
> 
> I don't see this as a grave problem.
> 
> >    * It tells the front end only the minimum information it needs to
> >      know. (developmental and unsupported interfaces are not printed)
> >      Again, this probably isn't to important.
> 
> Indeed.
> 
> > What is wrong with the handshaking protocol that I described?
> 
> It is too complicated for the job, IMHO.

Can I sum up the solutions we have, because it's obvious that we are not
interested in solving the problem the same way. You and I are on the
opposite side of each different type of solution that we come up with
and this is why it is taking a very long time to reach a middle point.

* printing just the latest stable version

   Is this the version that GDB will start up in if you do -i=mi even if
   you are using a CVS snapshot and the version has been bumped?

   This solution is lacking. It only tells the front end the latest
   stable version of the MI protocol. The front end can only guess what
   other stable versions are available and I consider this unacceptable.

   For CVS snapshots, if the above questions is true, then it will
   always print out the latest stable version and it will be
   communicating not in that version. This requires a restart no matter
   what.

   This does not satisfy the minimum amount of information that I need.

* printing all of the tested MI versions.

   This solution is basically my 'command line switch' solution.

   This is the minimum information that I need. A front end that
   wants to work with GDB will need to know every version of the MI
   protocol that the particular GDB was tested with.

   However, this solution requires starting GDB twice, which I would not
   prefer if it was solvable with just starting it once.

* creating a handshaking protocol

   This is the optimal solution since it gives the front end all of the
   tested MI versions and then allows the front end to select which
   version GDB should use. This is the solution I prefer. It requires
   GDB asking the front end for the version, and the other solutions do
   not require this.

   It could be as simple as outputting all of the tested MI versions one
   line at a time and then allowing the front end to select one or it
   could be more complicated like the grammar that I posted earlier.

Thanks,
Bob Rossi