From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1958 invoked by alias); 13 Nov 2013 22:03:38 -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 1946 invoked by uid 89); 13 Nov 2013 22:03:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: nick.hrz.tu-chemnitz.de Received: from Unknown (HELO nick.hrz.tu-chemnitz.de) (134.109.228.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 13 Nov 2013 22:03:35 +0000 Received: from 91-65-57-145-dynip.superkabel.de ([91.65.57.145] helo=localhost) by nick.hrz.tu-chemnitz.de with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VgiWz-0008Q6-3S; Wed, 13 Nov 2013 23:03:25 +0100 Date: Thu, 14 Nov 2013 00:36:00 -0000 From: =?iso-8859-1?Q?Andr=E9_P=F6nitz?= To: Joel Brobecker Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [RFC] New GDB/MI command "-info-gdb-mi-command" Message-ID: <20131113220322.GA5618@klara.mpi.htwm.de> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131113021514.GG3481@adacore.com> X-purgate: clean X-purgate-type: clean X-purgate-ID: 154106::1384380205-000004FB-E0F4EAC9/0-0/0-0 X-Scan-AV: nick.hrz.tu-chemnitz.de;2013-11-13 23:03:25;b0687f0c6f2c4a7a215f508199bc19a4 X-Scan-SA: nick.hrz.tu-chemnitz.de;2013-11-13 23:03:25;c84f509c207373fb2707c4a46d6c0b22 X-Spam-Score: -1.0 (-) X-Spam-Report: --- Textanalyse SpamAssassin 3.3.1 (-1.0 Punkte) Fragen an/questions to: Postmaster TU Chemnitz * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP --- Ende Textanalyse X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00359.txt.bz2 On Wed, Nov 13, 2013 at 06:15:14AM +0400, Joel Brobecker wrote: > > 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. For me the context was "frontends". I assume they run external tools in an environment that's as predictable as they need. If a user defined LANG is problematic for a frontend, I would assume the frontend forces debugger startup in a LANG that it knows to handle. > 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. I also assumed that such error message will not start with "Undefined MI command:". > > 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. That's fine. You want a feature, and you implement it, and you are in a position to get it in. I was merely jumping on the plural in "frontend_s_" and only because I mistook that as "all", not as "possibly more than one". > > 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. We really aren't. "python" is an obvious case, but I could also have used "thread-info" as example. Why should a frontend ask whether "-thread-info" is supported, parse output, and switch code paths between "-thread-info" and "info threads" (and hope that an announcement of "-thread-info" existence is backed by an implementation) when it could just fire "-thread-info" and handle a possible error by falling back on "info thread"? This would mean that users of well-behaved gdb builds/installation lose one roundtrip, and the frontend needs to implement three funtions (ask, either, or) instead of two (call, fallback) > 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. I was indeeed trying to make a general point insofar as that I think it does not help users to introduce, or strengthen, a _third_ way to describe "the state of the nation" (first being actual behaviour of the code, second the documentation, potential third the -info-gdb-mi-command output). I actually think this very thread proves the point. You said "Recently, I added new coommands for Ada exception$ catching, but forgot about -list-features" which means there _are_ builds of gdb which support the feature, but don't announce it. Anyway, to finish this: My fourth assumption was that the "[RFC]" in the subject was short-hand for "Request for comments" and that "interested parties" were invited to comment. But I got it now. Regards, Andre'