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

[Joel Brobecker <brobecker@adacore.com>]

> I am not sure I agree with the judgement of benefits here. The basic 
> yes/no information is already there:
> 
>     (gdb) -unsupported-command
>     ^error,msg="Undefined MI command: unsupported-command"
>     (gdb) -symbol-list-lines
>     ^error,msg="-symbol-list-lines: Usage: SOURCE_FILENAME"
> 
> It's not nice, but "works".

I disagree with your assessment of "works". I can think of a number
of scenarios where this would be problematic:

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. And if you base your detection
on the presence of the error alone, then commands that take no argument
may return an error, which by no means indicates that the command does not
exist.

> In addition, a yes-or-no is not even what might be needed.

Well, the IDE team at AdaCore needs that information in order to
support the variety of GDB versions out there, and I also agreed
with them that this was a sensible request.

> Look e.g. at the "python" advertisement in -list-features output
> ^done,features=["frozen-varobjs","pending-breakpoints","thread-info",
> "data-read-memory-bytes","breakpoint-notifications","ada-task-info","python"]
> 
> It does not indicate whether it is properly installed (datadir...) nor
> whether the version of Python is compatible with the script I want to
> execute. So in practice, checking -list-features is just extra effort
> giving only a subset of the information I would need for an "ok to use"
> decision, and it's quicker and more reliable to just execute the command
> and handle errors.
> 
> It's hard to imagine that this will ever cover enough of GDB features
> and questions a frontend needs to have answered.

If we were discussing about the specific issues regarding the use of
Python in your example, I would say that this is outside the scope of
this new command.

If you are trying to make a general point, then can you please tell
us how you think we can improve it? If not, you are free to find it
useless and to prefer to just use your execution test. But I definitely
think it's cleaner to query the debugger with a well documented interface,
rather than relying on detecting certain kinds of errors.

-- 
Joel