From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24632 invoked by alias); 6 Oct 2004 16:57:45 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 24611 invoked from network); 6 Oct 2004 16:57:43 -0000 Received: from unknown (HELO sadr.equallogic.com) (66.155.203.134) by sourceware.org with SMTP; 6 Oct 2004 16:57:43 -0000 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i96GvgFr026080 for ; Wed, 6 Oct 2004 12:57:42 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i96Gvgsw026075; Wed, 6 Oct 2004 12:57:42 -0400 Received: from pkoning.equallogic.com ([172.16.1.220]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 6 Oct 2004 12:57:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16740.9220.368095.137426@gargle.gargle.HOWL> Date: Wed, 06 Oct 2004 17:00:00 -0000 From: Paul Koning To: bob@brasko.net Cc: eliz@gnu.org, drow@false.org, gdb@sources.redhat.com Subject: Re: GDB/MI snapshots between major release's References: <20041003163918.GB7030@white> <01c4a9ce$Blat.v2.2.2$d01969a0@zahav.net.il> <20041004131906.GB8121@white> <200410041533.i94FXsPa014648@juw15.nfra.nl> <20041004155805.GF8121@white> <01c4aabb$Blat.v2.2.2$e64c8fc0@zahav.net.il> <20041005140736.GC13586@nevyn.them.org> <01c4ab8d$Blat.v2.2.2$93dba3c0@zahav.net.il> <20041006112703.GB11747@white> <01c4ab9f$Blat.v2.2.2$e9a87e60@zahav.net.il> <20041006164621.GC12213@white> X-OriginalArrivalTime: 06 Oct 2004 16:57:41.0934 (UTC) FILETIME=[97F1F4E0:01C4ABC5] X-SW-Source: 2004-10/txt/msg00140.txt.bz2 >>>>> "Bob" == Bob Rossi 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 >> > Cc: Daniel Jacobowitz , >> 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. 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