From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31557 invoked by alias); 6 Oct 2004 18:50:36 -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 31546 invoked from network); 6 Oct 2004 18:50:35 -0000 Received: from unknown (HELO lakermmtao12.cox.net) (68.230.240.27) by sourceware.org with SMTP; 6 Oct 2004 18:50:35 -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 <20041006185034.GFHU10352.lakermmtao12.cox.net@white>; Wed, 6 Oct 2004 14:50:34 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CFGry-0003O9-00; Wed, 06 Oct 2004 14:50:34 -0400 Date: Wed, 06 Oct 2004 18:54:00 -0000 From: 'Bob Rossi' To: Andrew Cagney Cc: Dave Korn , 'Eli Zaretskii' , gdb@sources.redhat.com Subject: Re: probing GDB for MI versions Message-ID: <20041006185034.GO12213@white> Mail-Followup-To: Andrew Cagney , Dave Korn , 'Eli Zaretskii' , gdb@sources.redhat.com References: <41643C45.4050407@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41643C45.4050407@gnu.org> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-10/txt/msg00172.txt.bz2 On Wed, Oct 06, 2004 at 02:41:09PM -0400, Andrew Cagney wrote: > > >>>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" > > anything like that. > > >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. > > Right, and tested (as always) using the testsuite. > > I find this focus on such pedantic details both puzzling and time > wasting. Especially given that any code intended to handle multiple MI > variants must be adhoc. Otherwize it won't work with all the variants > that pre-date the above - mi0, mi1, mi2 (prior to the above extension. You are stating that a parser that implements an MIn Output syntax has to be adhoc? I plan on having a parser for each of these interface's and none of them is adhoc. I don't think you should force your adhoc approach onto the front end developers. > MI needs is additional commands and extensions, driven by the needs of > Free software projects. Neither of those - EMACS and Eclipse - appear > to be having problems this technical nits such as this. I can't explain why. Bob Rossi