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

[Pedro Alves <palves@redhat.com>]

On 11/15/2013 03:30 AM, Joel Brobecker wrote:
>> Pedro> Just a POC.  Of course, we'd have to go audit all MI "error" calls.
>>
>> It seems like a reasonable idea to me.
> 
> The idea of a specific and documented error code seems much more robust
> to me.
> 
> Regarding invalid switches, we may have to extend the current proposal
> to allow the command to specific what in the usage caused problem?

Not sure about that.  Sounds more complicated than it's worth it.

> In my proposal, it was easy to extend by adding a "feature=[...]"
> list to the output. Or maybe that's overkill? Or use list-features
> for that instead?

As list-features already exists, and works just as well, that might
indeed be overkill.  Or put another way, is there a use case that
list-features doesn't cover, or something about "feature=[]"
that'd make ours and frontend writers' lives easier?  Just like with
list-features, we'd always have to manually take care of listing the
new command feature in "features=[]", so on our end it doesn't seem
to buy anything.
IOW, thinking in terms of KISS seems to suggest sticking with
list-features.

> I'd like us to decide to something I can go and implement. Either way,
> I think we can start by concentrating with the initial goal, which is
> to determine whether a command exists or not.

Yeah.  I have no problem with your proposal.  There's actually one
case where it works, and '^error,code="unknown-command"' does not,
which is when a command works and has effects without options.  In such
cases, you can't probe for the command's existence without causing
the (side) effects.

> People seem to have reacted
> more positively to the idea of try-and-fallback approach, shall we go
> with Pedro's idea (without the "invalid switch"/"usage" part)?

If I had infinite time, I'd go for all of the above.  Command to
probe existence of commands, and make ^error indicate both
unknown command, and bad usage.  :-)

-- 
Pedro Alves