From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20624 invoked by alias); 7 Oct 2004 14:15:29 -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 3012 invoked from network); 7 Oct 2004 14:04:56 -0000 Received: from unknown (HELO lakermmtao01.cox.net) (68.230.240.38) by sourceware.org with SMTP; 7 Oct 2004 14:04:56 -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 <20041007140456.SUNH19326.lakermmtao01.cox.net@white>; Thu, 7 Oct 2004 10:04:56 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1CFYt5-0003kc-00; Thu, 07 Oct 2004 10:04:55 -0400 Date: Thu, 07 Oct 2004 14:37:00 -0000 From: 'Bob Rossi' To: Dave Korn Cc: 'Eli Zaretskii' , gdb@sources.redhat.com Subject: Re: probing GDB for MI versions Message-ID: <20041007140455.GA14402@white> Mail-Followup-To: Dave Korn , 'Eli Zaretskii' , gdb@sources.redhat.com References: <20041007123557.GA14264@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/msg00209.txt.bz2 On Thu, Oct 07, 2004 at 01:48:04PM +0100, Dave Korn wrote: > > -----Original Message----- > > From: 'Bob Rossi' > > Sent: 07 October 2004 13:36 > > > > Yes, I can, but I'm not going to do it for you. Here's a > > hint, in shell > > > terms: > > > > > > echo "-mi-version" | gdb | grep "Highest supported MI > > version is" | .... > > > > > > [you have to fill in the ... with some kind of sed or awk command] > > > OK, I agree with this. Why would we add this functionality as > > an MI command > > if the front ends all have to write some adhoc parser to get the > > information? > > You use the term "adhoc parser" as if that were a bad thing. It's not. > It's an entirely reasonable way for a computer program to parse some data > and extract some simple information that it requires. You seem like you want "more of the old". GDB has come a long way from the adhoc parsers the front end's had to generate to deal with the CLI. The MI developers, wise as they are, decided to formalize the way GDB output's data and front end developers parse it. > > So, I agree that it can be done, I just think it's a terrible idea. > > We can do it in a much better way. > > This is an invalid argument. You'll have to have *some* kind of 'parsing' > going on in order to interpret the output from gdb that lists the versions > of MI, no matter whether it's an MI command or a command-line option or > anything else. So why you think one of those ways is terrible and the other > is not, on the basis of this requirement, which is in fact the same in both > cases anyway, I just don't see. Getting the data, one line at a time, not in the context of an MI Output command is fine with me. It has nothing to do with MI and I like that. I have thought about this long enough to have come to a conclusion. I think it is silly to add an MI command to GDB that can not be used by a front end that speaks the MI protocol. * Let's make this clear, MI commands are there for front ends that speak the MI protocol. The solution of adding an MI command that can only be looked at by an adhoc parser and making rules like "the command will never change" is non-intuitive and confusing. Having a simple mechanism, such as a command line switch or a new interpreter, would be simple and understandable. Thanks, Bob Rossi