From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9829 invoked by alias); 14 Nov 2013 18:29:10 -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 9816 invoked by uid 89); 14 Nov 2013 18:29:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: cora.hrz.tu-chemnitz.de Received: from Unknown (HELO cora.hrz.tu-chemnitz.de) (134.109.228.40) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 14 Nov 2013 18:27:27 +0000 Received: from 91-65-61-95-dynip.superkabel.de ([91.65.61.95] helo=localhost) by cora.hrz.tu-chemnitz.de with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Vh1dN-00027Q-CF; Thu, 14 Nov 2013 19:27:18 +0100 Date: Thu, 14 Nov 2013 18:31: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: <20131114182716.GA3327@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> <20131113220322.GA5618@klara.mpi.htwm.de> <20131114093253.GM3481@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131114093253.GM3481@adacore.com> X-purgate: clean X-purgate-type: clean X-purgate-ID: 154106::1384453637-000004C5-4FE5550B/0-0/0-0 X-Scan-AV: cora.hrz.tu-chemnitz.de;2013-11-14 19:27:17;61a4d68a0d74a7854579f926cb881c40 X-Scan-SA: cora.hrz.tu-chemnitz.de;2013-11-14 19:27:18;d82f7441bb2ecd05f02ba05f07941d51 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/msg00381.txt.bz2 On Thu, Nov 14, 2013 at 01:32:53PM +0400, Joel Brobecker wrote: > > 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). I think it's ok to let the frontend align debugger message output with the needs of the frontend's users. This might be translated output, it might be untranslated output, it might even be something re-phrased by the frontend. Especially for frontends supporting more than one debugger backend, each with different terminology, I see some value in using backend-agnostic messaging. It's nice that GDB provides translations, it's also nice that it gives the option to be used untranslated. [When I think about it, it's not even either-or. "Message based feature discovery" could use an second untranslated debugger instance, while the actual debugging runs in a trancelated instance...] > > 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. Unless the frontend bundles a "verified" build of the debugger it has to cope with what's installed in the system. That needs feature discovery, one way or the other, including recognition of what it considers "bad" installation, "bad" from the frontend's point of view, not necessarily from the distribution's point of view. > > 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, I did mean the manual. It's now certainly much better aligned to the implementation, especially for the MI bits, than it was at the 6.x times, but there are still discrepancies every now and then. Btw, one thing that I feel missing there are hints about the first appearance of a feature. Even when a frontend is ready to limit the range of supported versions of GDB', e.g. to "only >= 7.2" or "only >= 7.4" it's really hard to find out whether it's "safe" to use a feature that's mentioned in the 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. I think we agree that -list-features does not scale well, and that -info-gdb-mi-command is conceptual better. We do not agree on the absolute practical utility of the feature, but that's not a problem. It was ... just a comment. Andre'