From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24039 invoked by alias); 15 Nov 2013 03:31:21 -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 24019 invoked by uid 89); 15 Nov 2013 03:31:20 -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; Fri, 15 Nov 2013 03:30:32 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 61C2C11648B; Thu, 14 Nov 2013 22:30:56 -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 R5N+aWZt-kT8; Thu, 14 Nov 2013 22:30:56 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id E5D69116449; Thu, 14 Nov 2013 22:30:55 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 96D3AE98AD; Fri, 15 Nov 2013 07:30:21 +0400 (RET) Date: Fri, 15 Nov 2013 05:35:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: Pedro Alves , =?iso-8859-1?Q?Andr=E9_P=F6nitz?= , gdb-patches@sourceware.org Subject: Re: [RFC] New GDB/MI command "-info-gdb-mi-command" Message-ID: <20131115033021.GT3481@adacore.com> References: <8761rzknb4.fsf@fleche.redhat.com> <1384255504-28444-1-git-send-email-brobecker@adacore.com> <20131112205229.GA7068@klara.mpi.htwm.de> <20131113021514.GG3481@adacore.com> <52851A04.6040004@redhat.com> <52851E57.30103@redhat.com> <87iovuwx7l.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87iovuwx7l.fsf@fleche.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2013-11/txt/msg00399.txt.bz2 > Pedro> Just a POC. Of course, we'd have to go audit all MI "error" calls. > > It seems like a reasonable idea to me. The idea of a specific and documented error code seems much more robust to me. Regarding invalid switches, we may have to extend the current proposal to allow the command to specific what in the usage caused problem? In my proposal, it was easy to extend by adding a "feature=[...]" list to the output. Or maybe that's overkill? Or use list-features for that instead? I'd like us to decide to something I can go and implement. Either way, I think we can start by concentrating with the initial goal, which is to determine whether a command exists or not. People seem to have reacted more positively to the idea of try-and-fallback approach, shall we go with Pedro's idea (without the "invalid switch"/"usage" part)? Thanks, -- Joel