From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7607 invoked by alias); 18 Dec 2006 15:39:32 -0000 Received: (qmail 7597 invoked by uid 22791); 18 Dec 2006 15:39:31 -0000 X-Spam-Check-By: sourceware.org Received: from centrmmtao02.cox.net (HELO centrmmtao02.cox.net) (70.168.83.82) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Dec 2006 15:39:24 +0000 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by centrmmtao02.cox.net (InterMail vM.6.01.06.03 201-2131-130-104-20060516) with ESMTP id <20061218153922.FPYW25837.centrmmtao02.cox.net@eastrmimpo01.cox.net>; Mon, 18 Dec 2006 10:39:22 -0500 Received: from black ([70.181.32.198]) by eastrmimpo01.cox.net with bizsmtp id 0FeG1W00H4GV2Jm0000000; Mon, 18 Dec 2006 10:38:16 -0500 Received: from bob by black with local (Exim 4.62) (envelope-from ) id 1GwKaH-00078d-53; Mon, 18 Dec 2006 10:39:21 -0500 Date: Mon, 18 Dec 2006 15:39:00 -0000 From: Bob Rossi To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: MI fine-grained versioning Message-ID: <20061218153921.GY20942@cox.net> Mail-Followup-To: Vladimir Prus , gdb@sources.redhat.com References: <200612181835.34025.vladimir@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200612181835.34025.vladimir@codesourcery.com> User-Agent: Mutt/1.5.12-2006-07-14 X-IsSubscribed: yes 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/msg00167.txt.bz2 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. 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? Thanks, Bob Rossi