From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17784 invoked by alias); 6 Oct 2004 18:09:12 -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 17763 invoked from network); 6 Oct 2004 18:09:09 -0000 Received: from unknown (HELO sadr.equallogic.com) (66.155.203.134) by sourceware.org with SMTP; 6 Oct 2004 18:09:09 -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 i96I96Fr031837 for ; Wed, 6 Oct 2004 14:09:07 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i96I95sw031832; Wed, 6 Oct 2004 14:09:05 -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 14:09:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16740.13503.362574.54307@gargle.gargle.HOWL> Date: Wed, 06 Oct 2004 18:19:00 -0000 From: Paul Koning To: bob@brasko.net Cc: dk@artimi.com, eliz@gnu.org, gdb@sources.redhat.com Subject: Re: probing GDB for MI versions References: <20041006173622.GJ12213@white> <20041006175117.GK12213@white> X-OriginalArrivalTime: 06 Oct 2004 18:09:04.0813 (UTC) FILETIME=[90BD6DD0:01C4ABCF] X-SW-Source: 2004-10/txt/msg00167.txt.bz2 >>>>> "Bob" == Bob Rossi 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