From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27644 invoked by alias); 6 Oct 2004 17:51: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 27637 invoked from network); 6 Oct 2004 17:51:17 -0000 Received: from unknown (HELO lakermmtao01.cox.net) (68.230.240.38) by sourceware.org with SMTP; 6 Oct 2004 17:51:17 -0000 Received: from white ([68.9.64.121]) by lakermmtao01.cox.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with ESMTP id <20041006175118.FBIK19326.lakermmtao01.cox.net@white>; Wed, 6 Oct 2004 13:51:18 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CFFwb-0003Kx-00; Wed, 06 Oct 2004 13:51:17 -0400 Date: Wed, 06 Oct 2004 17:55:00 -0000 From: 'Bob Rossi' To: Dave Korn Cc: 'Eli Zaretskii' , gdb@sources.redhat.com Subject: Re: probing GDB for MI versions Message-ID: <20041006175117.GK12213@white> Mail-Followup-To: Dave Korn , 'Eli Zaretskii' , gdb@sources.redhat.com References: <20041006173622.GJ12213@white> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00162.txt.bz2 On Wed, Oct 06, 2004 at 06:41:05PM +0100, Dave Korn wrote: > > -----Original Message----- > > From: Bob Rossi [mailto:bob@brasko.net] > > > > 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) > > False inference. I don't believe it's false yet. > > 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. Unfortunatly you are only thinking of the output of the MI command. Not the actual syntax of the MI output. This could change and you have to deal with it. So, to restate, 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) Dave, can you write a piece of code that can take all of the output of GDB, from when it starts until after it exists (only given this new MI command), and return to me the currently supported interfaces? Will this code work with MI5, MI6 and MI7. Since it is likely that there will be syntax changes? Thanks, Bob Rossi