Re: probing GDB for MI versions

Paul Koning
2004-10-06T18:09:12Z

>>>>> "Bob" == Bob Rossi <Bob> writes:

Bob> On Wed, Oct 06, 2004 at 06:41:05PM +0100, Dave Korn wrote:
>> > -----Original Message----- > From: Bob Rossi

>> > Will someone explain to me how they expect to write a parser >
>> capable of > getting some information out of MI2, but prove to me
>> that it will work > with MI100.
>>
>> Simple.
>>
>> Any time anyone proposes changing the output format of the
>> -mi-version command, or removing it, we'll just say no. Fr'ex:
>>
>> The -mi-version command will ALWAYS AND FOREVER output a string of
>> the format
>>
>> "Highest supported MI version is XXXX"
>>
>> where XXXX is an ASCII decimal integer. Any program can then read
>> the output from an invocation of gdb and simply discard everything
>> up until it finds that string, then parse the integer out.

Bob> Unfortunatly you are only thinking of the output of the MI
Bob> command. Not the actual syntax of the MI output. This could
Bob> change and you have to deal with it.

No, Dave is right. This is how protocol version handling is done in
protocol design practice.

The key point is this:

a. There is a well-defined way to convey the protocol version
information early on in the exchange. It may come as part of the
startup message -- if there is such a thing. Or it may be
a reply to a query that is allowed in the initial state.

b. The following items are immutable across versions:
1. The subset of parsing rules you need to find the version
data. That need not be a full parse; for example, it can
be something as simple as "the first 5 bytes of the first
message you receive". Or it might be "tag 42 of the
tag/length/value encoded payload of the first message is
the version number".
2. The query that gets you the message -- if a query is used.

So the MI evolution is constrained only enough that such a version
mechanism can be defined, and no more than that.

paul