From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3909 invoked by alias); 12 Feb 2004 22:34:09 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 3901 invoked from network); 12 Feb 2004 22:34:06 -0000 Received: from unknown (HELO lakemtao03.cox.net) (68.1.17.242) by sources.redhat.com with SMTP; 12 Feb 2004 22:34:06 -0000 Received: from white ([68.9.64.121]) by lakemtao03.cox.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040212223407.JLYB2192.lakemtao03.cox.net@white>; Thu, 12 Feb 2004 17:34:07 -0500 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1ArPPJ-00019V-00; Thu, 12 Feb 2004 17:34:05 -0500 Date: Thu, 12 Feb 2004 22:34:00 -0000 From: Bob Rossi To: Nick Roberts Cc: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: RFA (?) Annotate Level 3 patch Message-ID: <20040212223405.GA4259@white> Mail-Followup-To: Nick Roberts , Andrew Cagney , gdb-patches@sources.redhat.com References: <16176.3560.65649.7079@nick.uklinux.net> <4016A245.6030001@gnu.org> <16414.51421.622553.831432@nick.uklinux.net> <40296BF1.7060900@gnu.org> <16427.62345.989794.926455@nick.uklinux.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16427.62345.989794.926455@nick.uklinux.net> User-Agent: Mutt/1.3.28i X-SW-Source: 2004-02/txt/msg00332.txt.bz2 > On a related matter, as the Machine Interface evolves, Emacs will have to do > different things for different versions of GDB, so it would be helpful if > "show version" ("-gdb-show version") or a related command gave a formally > defined increasing version number. In Emacs, the last release is 21.3.1 and > the version in CVS is 21.3.50. In GDB, the last release is 6.0 but the version > in CVS is 2004-02-01-cvs, say. Also releases, like 5.3postxxxx.. exist. This is also a real concern of mine. I would like to see a formal printing of GDB/MI's version number. I think that starting gdb like gdb --show-gdbmi-version should output the version in an MI parable way. Also, another problem exists which Nick brings up. When distro's package GDB from CVS ( debian ), how should the front end determine what MI version is being used? It is possible that the version number has not formally changed, however several MI commands might have been modified. In this case, it would be necessary to make all commands backwards compatible, and the front end wouldn't be able to take advantage of commands that might be useful. An approach to solving this could be, when the front end wants to know the version, GDB could print the MI version of each function it supports. So, gdb --show-gdbmi-version ^done,[{mi_function="-break-info",version=1},{mi_function="-break-list",version=2}] Would this be overkill? Also, as each MI command changes, the documentation must provide the interface for that MI command for each version. Bob Rossi