Re: probing GDB for MI versions

[Bob Rossi <bob at brasko dot net>]

On Thu, Oct 07, 2004 at 10:12:40AM -0700, Felix Lee wrote:
> 'Bob Rossi' <bob@brasko.net>:
> > 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, that is why I am arguing on the side of not
> > adding this command to the MI function set, but solving the problem
> > another way.
> 
> ... I'm lost.  if I apply your statement to a different context,
> you seem to be saying that gdb's "show version" command is a
> nonsensical and confusing way of determining what version gdb is,
> and there should be an out-of-band method of determining gdb
> version.
> 
> this seems to me obviously wrong, because there are many
> situations where you're limited to serial communication with a
> remote agent, so it isn't possible to get out-of-band
> information.
> 
> that situation is unlikely to happen with gdb itself, since in
> any sane situation you're going to be able to invoke gdb with
> arbitrary command switches.  but that's unusual rather than
> typical.  most communication protocols need an in-band method of
> determining protocol version.

I am not sure when you say "out of band", if you are refering to 
GDB/MI's out of band record in the MI output syntax.

I do understand what you are saying, and I agree with you. Some
protocols allow for the version communication to take place within the
protocol. This makes the most sense to me.

For instance, XML allows the first line of the document to have the
version number. From then on, it can use the correct parser to process
the document. If the version number is not there, it can only guess at
what's in the document, and errors can occcur. Basically, the version
number is in a format the client can understand and then the client can
choose the appropriate parser based off of this.

I think adding an MI command to get the version is not the solution to
this problem. Calling an MI command assumes that you already know the
protocol, and then you can call the MI function. Otherwise, you are not
necessarily handshaking, but you have to write the adhoc parser to get
the information you need.

For instance, if GDB supported 1 stable MI protocol, if it is an
official release or a CVS snapshot, then the first thing GDB could
output to the front end is the version of MI that it is communicating.

If we wanted to be even more verbose, we could 

   * define a syntax for an MI header that communicated to the front 
     end all of the necessary things it would need to know before 
     initializing it's protocol.

   * we could always handshake using the MI2 protocol, even though the
     protocol that GDB supports is a higher version. 
     
For option 2, this means that GDB would not necessarily support MI2, 
but it would handshake in that protocol, since it will probably never 
need to change for backward incompatibilities. This has the downside 
of forcing new front ends to be able to implement the MI2 protocol, 
which is probably not a good idea.

Any comments?

Thanks,
Bob Rossi