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: GDB/MI snapshots between major release's


>>>>> "Bob" == Bob Rossi <bob@brasko.net> writes:

 Bob> On Wed, Oct 06, 2004 at 02:26:55PM +0200, Eli Zaretskii wrote:
 >> > Date: Wed, 6 Oct 2004 07:27:03 -0400 > From: Bob Rossi
 >> <bob@brasko.net> > Cc: Daniel Jacobowitz <drow@false.org>,
 >> gdb@sources.redhat.com
 >> > 
 >> > > First, it is possible that when the front end knows which MI
 >> version > > is the last stable one, it will not need to restart
 >> GDB, but just > > arrange for the appropriate parser to be used
 >> for the rest of the > > session.
 >> > 
 >> > This is not correct. The front end has parsers for different
 >> versions of > GDB's MI protocol. The parser for MI2 will not work
 >> for the MI3 protocol
 >> 
 >> In general, it won't, but for a very specific case of
 >> _a_single_command_, it could very well do.

 Bob> You obviously not understanding the point here. I can not even
 Bob> get my front end to the point where it can look at the
 Bob> command. The reason is, I can not *PARSE* the command.

 Bob> Here is a simple explanation that I have tried to discuss over
 Bob> and over.
   
 Bob> 1. Each version of MI comes with a grammar.  2. If the MI
 Bob> grammar changes between MI1 and MI2 then 3. A parser is
 Bob> generated that understands the grammar for MI1 4. A parser is
 Bob> generated that understands the grammar for MI2 5. The parser for
 Bob> MI1 *will not parse* the output of MI2 6. The parser for MI2
 Bob> *will not parse* the output of MI1

I'm puzzled.  If MI2 is a superset of MI1, then the parser for MI2 by
definition will parse any string in MI1.  And generalizing, unless MI1
and MI2 have essentially nothing in common, I don't see how it can be
true that you cannot parse any command at all.

Just as in any protocol, you need version numbers to cope with the
situation where a new MIx is NOT just a superset of MI<x-1>.  But the
usual picture of protocol evolution is that those cases are not all
that common -- most evoluation creates supersets.

(And incidentally, a version numbering scheme would have to rely on
the restriction that a certain defined part of the protocol is
immutable, or at least allows no changes other than supersetting --
and that part conveys version information.)

     paul


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