This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: probing GDB for MI versions
>>>>> "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