From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14098 invoked by alias); 18 Dec 2006 16:02:23 -0000 Received: (qmail 13844 invoked by uid 22791); 18 Dec 2006 16:02:22 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Dec 2006 16:02:16 +0000 Received: (qmail 24771 invoked from network); 18 Dec 2006 16:02:14 -0000 Received: from unknown (HELO ?172.16.64.38?) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Dec 2006 16:02:14 -0000 From: Vladimir Prus To: Bob Rossi Subject: Re: MI fine-grained versioning Date: Mon, 18 Dec 2006 16:02:00 -0000 User-Agent: KMail/1.9.1 Cc: gdb@sources.redhat.com References: <200612181835.34025.vladimir@codesourcery.com> <20061218153921.GY20942@cox.net> In-Reply-To: <20061218153921.GY20942@cox.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612181902.02350.vladimir@codesourcery.com> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00169.txt.bz2 On Monday 18 December 2006 18:39, Bob Rossi wrote: > On Mon, Dec 18, 2006 at 06:35:33PM +0300, Vladimir Prus wrote: > > > > At the moment, MI does not have any mechanism to announce supported > > features. For example, I have a patch to add "frozen" variable objects. To support > > such feature in a backward-compatible fashion, the frontend must know if that > > features is supported by the given gdb binary. > > > > Using version number is not very reliable -- for example if you use the CVS state > > of gdb, the version number is not yet bumped. > > > > Yet another approach is to "detect" presence of feature by trying some commands, > > or by trying commands with some new options, or by constructing more contrived test > > cases. However that's troublesome. > > > > How about adding new MI command that returnes list of supported fine-grained features. > > For example: > > > > -list-features > > ^done,result=["frozen_variables","info_path_expression"] > > > > The MI manual would contain a section listing all feature names and briefly documenting them. > > Great idea! > > There are a few gothcha's. For instance, each command can support > several parameters, so you might want to report on that. Yes. For example if -var-registers end up being -var-create --registers we'd need a feature name. > But more > tricky, is when a command adds an output field that the front end cares > about. An example of this would be that the -break-list command has > always existed, but the -break-list command added fullpath functionality > later on it it's life. How would you handle this, if at all? That's actually easy. If a frontend can handle the extra field locally, then we don't need new element in -list-features. If it cannot, we need new element. This "can" and "cannot" is determined by hacking the relevant support in KDevelop. If an author of some other frontend wants new item in -list-features, that element is added too. It's generally easier to add new elements to -list-features as frontend authors request, then argue about "inherent" need to announce a specific change. - Volodya