Re: [RFC] New GDB/MI command "-info-gdb-mi-command"

[André Pönitz <andre dot poenitz at mathematik dot tu-chemnitz dot de>]

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'