From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17327 invoked by alias); 13 Nov 2013 02:15:28 -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 17311 invoked by uid 89); 13 Nov 2013 02:15:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_50,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; Wed, 13 Nov 2013 02:15:25 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 36446116560; Tue, 12 Nov 2013 21:15:49 -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 vEJocBC8JU5c; Tue, 12 Nov 2013 21:15:49 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id B7B7811645B; Tue, 12 Nov 2013 21:15:48 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 11E79E0735; Wed, 13 Nov 2013 06:15:14 +0400 (RET) Date: Wed, 13 Nov 2013 02:47:00 -0000 From: Joel Brobecker To: =?iso-8859-1?Q?Andr=E9_P=F6nitz?= Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFC] New GDB/MI command "-info-gdb-mi-command" Message-ID: <20131113021514.GG3481@adacore.com> References: <8761rzknb4.fsf@fleche.redhat.com> <1384255504-28444-1-git-send-email-brobecker@adacore.com> <20131112205229.GA7068@klara.mpi.htwm.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131112205229.GA7068@klara.mpi.htwm.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2013-11/txt/msg00332.txt.bz2 > I am not sure I agree with the judgement of benefits here. The basic > yes/no information is already there: > > (gdb) -unsupported-command > ^error,msg="Undefined MI command: unsupported-command" > (gdb) -symbol-list-lines > ^error,msg="-symbol-list-lines: Usage: SOURCE_FILENAME" > > It's not nice, but "works". I disagree with your assessment of "works". I can think of a number of scenarios where this would be problematic: The first and most obvious to me is the case where the debugger is run with a non-English LANG. If you base your detection on parsing the error msg, then i18n ruins your plan. And if you base your detection on the presence of the error alone, then commands that take no argument may return an error, which by no means indicates that the command does not exist. > In addition, a yes-or-no is not even what might be needed. Well, the IDE team at AdaCore needs that information in order to support the variety of GDB versions out there, and I also agreed with them that this was a sensible request. > Look e.g. at the "python" advertisement in -list-features output > ^done,features=["frozen-varobjs","pending-breakpoints","thread-info", > "data-read-memory-bytes","breakpoint-notifications","ada-task-info","python"] > > It does not indicate whether it is properly installed (datadir...) nor > whether the version of Python is compatible with the script I want to > execute. So in practice, checking -list-features is just extra effort > giving only a subset of the information I would need for an "ok to use" > decision, and it's quicker and more reliable to just execute the command > and handle errors. > > It's hard to imagine that this will ever cover enough of GDB features > and questions a frontend needs to have answered. If we were discussing about the specific issues regarding the use of Python in your example, I would say that this is outside the scope of this new command. If you are trying to make a general point, then can you please tell us how you think we can improve it? If not, you are free to find it useless and to prefer to just use your execution test. But I definitely think it's cleaner to query the debugger with a well documented interface, rather than relying on detecting certain kinds of errors. -- Joel