From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1806 invoked by alias); 6 Oct 2004 17:58:19 -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 1761 invoked from network); 6 Oct 2004 17:58:17 -0000 Received: from unknown (HELO lakermmtao12.cox.net) (68.230.240.27) by sourceware.org with SMTP; 6 Oct 2004 17:58:17 -0000 Received: from white ([68.9.64.121]) by lakermmtao12.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041006175816.FMME10352.lakermmtao12.cox.net@white>; Wed, 6 Oct 2004 13:58:16 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CFG3M-0003Li-00; Wed, 06 Oct 2004 13:58:16 -0400 Date: Wed, 06 Oct 2004 18:09:00 -0000 From: Bob Rossi To: Paul Koning Cc: dk@artimi.com, eliz@gnu.org, gdb@sources.redhat.com Subject: Re: probing GDB for MI versions Message-ID: <20041006175816.GL12213@white> Mail-Followup-To: Paul Koning , dk@artimi.com, eliz@gnu.org, gdb@sources.redhat.com References: <20041006170513.GG12213@white> <20041006172138.GI12213@white> <16740.12237.42548.798398@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16740.12237.42548.798398@gargle.gargle.HOWL> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00166.txt.bz2 On Wed, Oct 06, 2004 at 01:47:57PM -0400, Paul Koning wrote: > >>>>> "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. Yes, you are correct. I understand this. I think the problem is 2 fold. It is confusing and (IMO) incorrect to add a command to the MI function set that can not be used for the purposes that it needs to be by a program that speaks the MI protocol. I new parser needs to be written that does not conform to the MI protocol. MI is an evolving protocol, and it would be useful to just have either a command line swith, which could send info in a trivial line based manner, or have a new interpreter, that only says what other interpreters that the current GDB supports. These are simple solutions that would not involve much from the front end developer and would result in code that could be written probably to a format that will not change. Thanks, Bob Rosi