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

[Joel Brobecker <brobecker at adacore dot com>]

> 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