From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7990 invoked by alias); 12 Nov 2013 07:58:18 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 7979 invoked by uid 89); 12 Nov 2013 07:58:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.2 X-HELO: rock.gnat.com Received: from Unknown (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 12 Nov 2013 07:58:16 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 148FA116687; Tue, 12 Nov 2013 02:58:40 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pfV98-93eqzl; Tue, 12 Nov 2013 02:58:40 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id A1F19116683; Tue, 12 Nov 2013 02:58:39 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 7BF77E1560; Tue, 12 Nov 2013 11:57:59 +0400 (RET) Date: Tue, 12 Nov 2013 09:18:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [RFC] Add ada-exception-catchpoints to -list-features command output. Message-ID: <20131112075759.GC3481@adacore.com> References: <1384076960-12339-1-git-send-email-brobecker@adacore.com> <8761rzknb4.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8761rzknb4.fsf@fleche.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2013-11/txt/msg00308.txt.bz2 > Joel> This patch adds an entry meant to help the frontend for those features. > Joel> But looking at the way the -list-features command is designed, I am > Joel> wondering whether this approach is going to scale well. As new commands > Joel> and other new features or major bug fixes get in, it seems like the > Joel> list is going to grow maybe a little beyond what's reasonable. > > We could add a way to check for specific commands. Then new commands > would never need to be added to the feature list. I like the idea. I need to think a bit about the actual API. I was thinking something along the lines of: -info-gdb-mi-command MI_COMMAND The first implementation would just return one field, which would say yay or nay. But eventually, it might be nice to add other properties, such as maybe some kind of versioning number to help track evolution of the command, or maybe a command-specific feature list. The latter might be less abstract/complex and extensible enough to fit all needs. So, for instance (if the following is valid GDB/MI syntax): -info-gdb-mi-command catch-load -^done,info={exists="true",features=['-c']} which would tell us that the -catch-load command exists, and that in this version of GDB, the "-c" features is supported, for instance telling us that it's possible to add a condition to the catchpoint. > > Joel> So, although this patch proposes a new field (this is the straightforward > Joel> approach), given that all this GDB/MI work was done within the same > Joel> release cycle, and withing a reasonable amount of time, I think it > Joel> would be fine for everyone to use one single field in -list-features. > > I think it is reasonable, too, provided that the MI docs note the > details of what the feature means. Of course. I will send a patch as soon as I have a moment. -- Joel