From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7029 invoked by alias); 14 Nov 2013 09:33:07 -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 7019 invoked by uid 89); 14 Nov 2013 09:33:06 -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; Thu, 14 Nov 2013 09:33:04 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 5E60E1166FF; Thu, 14 Nov 2013 04:33:28 -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 KR72TXqrx6jS; Thu, 14 Nov 2013 04:33:28 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id DDFB211637F; Thu, 14 Nov 2013 04:33:27 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 7C3F8E0CD6; Thu, 14 Nov 2013 13:32:53 +0400 (RET) Date: Thu, 14 Nov 2013 09:48: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: <20131114093253.GM3481@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> <20131113220322.GA5618@klara.mpi.htwm.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131113220322.GA5618@klara.mpi.htwm.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2013-11/txt/msg00363.txt.bz2 > 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. I actually welcome comments, and you were right about the meaning of the "RFC". But receiving comments does not necessarily means agreeing with all of them. We're having a discussion, and I am trying to explain why I think the approach you are suggesting is not as practical as the one I am proposing. > > 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. The problem with overriding the user's LANG settings, is that you are essentially turning i18n off, thus forcing the user to see all messages from the debugger in English. Many people find that unacceptable, and I would agree with them. Besides, we've done a fair amount of work to allow i18n, so it would be a shame to see that turned off by a frontend, just to because they depend on the wording of a specific error message (which may change, btw). > 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) I agree that FEs shouldn't be in the business of verifying that the underlying debugger is correctly built or installed. That's not what the new command is about. > 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). OK, I see. You're objecting to the concept itself, not the command. My stance is that I have a different assessment of the situation. I hope you'll understand why I personally think your first way (behavior of the code) is not practical - you even had to quote "works" when you proposed your approach; for the second (documentation), I hope you mean "-list-features" and not the GDB manual, and I explained why I think this is not going to scale well; that's why Tom proposed the idea of this new command. Remember also that I think the current design leaves the door open for providing more information. For instance, we could let command announce features added after the command creation. > 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. Very possible. But I am pretty sure that no FE actually uses those features, yet - not even the AdaCore FE, since I haven't announced the feature to them yet either. For those few builds, it's OK for the FE to use the fallback mechanism. -- Joel