From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11652 invoked by alias); 6 Oct 2004 17:36:24 -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 11643 invoked from network); 6 Oct 2004 17:36:23 -0000 Received: from unknown (HELO lakermmtao09.cox.net) (68.230.240.30) by sourceware.org with SMTP; 6 Oct 2004 17:36:23 -0000 Received: from white ([68.9.64.121]) by lakermmtao09.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041006173623.EYGA15258.lakermmtao09.cox.net@white>; Wed, 6 Oct 2004 13:36:23 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CFFiA-0003J2-00; Wed, 06 Oct 2004 13:36:22 -0400 Date: Wed, 06 Oct 2004 17:38:00 -0000 From: Bob Rossi To: Dave Korn , 'Eli Zaretskii' , gdb@sources.redhat.com Subject: Re: probing GDB for MI versions Message-ID: <20041006173622.GJ12213@white> Mail-Followup-To: Dave Korn , 'Eli Zaretskii' , gdb@sources.redhat.com References: <20041006170513.GG12213@white> <20041006172138.GI12213@white> <20041006172403.GA8694@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041006172403.GA8694@nevyn.them.org> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00154.txt.bz2 On Wed, Oct 06, 2004 at 01:24:03PM -0400, Daniel Jacobowitz wrote: > On Wed, Oct 06, 2004 at 01:21:38PM -0400, 'Bob Rossi' wrote: > > I guess the bottom line is, I already have a parser that is capable of > > dealing with a specific version of MI's output. I don't want to start up > > MI with an adhoc parser, just to figure out what real parser I should > > use. This seems not correct to me, and I guess it's the issue to deal > > with. > > You've got a hammer and are attempting to create a nail. It seems > eminently correct to me, and to Dave too I think. Unfortunately, I don't understand what this means. Could you please explain? I want to make one thing clear, Eli's suggesting of making an MI command that returns the supported MI versions has one problem. We are adding a command to an MI protocol that can not be understood by a program that can speak a protocol. The program must, 1. Have a parser that understands the protocol it wants to speak (obvious and easy to get) 2. Have a parser that understands all future non invented protocols of the MI output syntax, and will be capable of parsing the current and future protocols to get the information it needs. (mostly not possible) 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. Thanks, Bob Rossi