From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-19743-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 22931 invoked by alias); 6 Oct 2004 18:41:38 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 22876 invoked from network); 6 Oct 2004 18:41:37 -0000
Received: from unknown (HELO mx1.redhat.com) (66.187.233.31)
  by sourceware.org with SMTP; 6 Oct 2004 18:41:37 -0000
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i96IfWJN015328
	for <gdb@sources.redhat.com>; Wed, 6 Oct 2004 14:41:37 -0400
Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i96IfUr14062;
	Wed, 6 Oct 2004 14:41:31 -0400
Received: from gnu.org (localhost [127.0.0.1])
	by localhost.redhat.com (Postfix) with ESMTP
	id A8B8A28D2; Wed,  6 Oct 2004 14:41:09 -0400 (EDT)
Message-ID: <41643C45.4050407@gnu.org>
Date: Wed, 06 Oct 2004 18:43:00 -0000
From: Andrew Cagney <cagney@gnu.org>
User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040831
MIME-Version: 1.0
To: Dave Korn <dk@artimi.com>
Cc: "'Bob Rossi'" <bob@brasko.net>, "'Eli Zaretskii'" <eliz@gnu.org>,
        gdb@sources.redhat.com
Subject: Re: probing GDB for MI versions
References: <NUTMEGGNhwO4fAT1Ily000002da@NUTMEG.CAM.ARTIMI.COM>
In-Reply-To: <NUTMEGGNhwO4fAT1Ily000002da@NUTMEG.CAM.ARTIMI.COM>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2004-10/txt/msg00170.txt.bz2


>>> 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.

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.

Andrew