This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]