From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24803 invoked by alias); 6 Oct 2004 17:48:00 -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 24782 invoked from network); 6 Oct 2004 17:47:59 -0000 Received: from unknown (HELO sadr.equallogic.com) (66.155.203.134) by sourceware.org with SMTP; 6 Oct 2004 17:47:59 -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 i96HlwFr030162 for ; Wed, 6 Oct 2004 13:47:59 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i96Hlwsw030157; Wed, 6 Oct 2004 13:47:58 -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 13:47:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16740.12237.42548.798398@gargle.gargle.HOWL> Date: Wed, 06 Oct 2004 17:51: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: <20041006170513.GG12213@white> <20041006172138.GI12213@white> X-OriginalArrivalTime: 06 Oct 2004 17:47:58.0554 (UTC) FILETIME=[9DFDA3A0:01C4ABCC] X-SW-Source: 2004-10/txt/msg00161.txt.bz2 >>>>> "Bob" == Bob Rossi writes: >> > Is this the general feel of the community? >> >> Well, it's not what I feel, as I hope I've explained patiently >> above. I wouldn't care to speak for the community at large, but I >> would be surprised if anyone else felt that it was wrong to >> generate a parser from the MI output syntax. What I feel is wrong >> is your assumption that a generated parser is the only possible >> means of processing plain ascii human readable text for the >> purpose of finding and extracting a single integer value. Bob> I guess the bottom line is, I already have a parser that is Bob> capable of dealing with a specific version of MI's output. I Bob> don't want to start up MI with an adhoc parser, just to figure Bob> out what real parser I should use. This seems not correct to me, Bob> and I guess it's the issue to deal with. Bob, that actually IS correct and the conventional way to handle things. In typical protocol design, the conversation starts with a message that carries version information. The protocol state machine initially comes up in a state where it expects that message and knows how to find the version information. Once it knows that, it flips to the state machine for that version. Note that the "ad hoc" part typically only involves one or two messages and often only a small part of the content of those messages. For example, the initial message might be a "create connection" message, carrying dozens of fields one of which is a version number. The first step is to find that version number; after that is known, all the rest including the full parse of that initial message can be done by the full parse machinery. (Alternatively, there might be a combined state machine -- in your notation, that would be a grammar for the union of MI1 and MI2, with condition checking on the version number to forbid certain production rules. That may work for some protocols; I doubt it's a sensible answer for MI.) paul