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

["André Pönitz" <andre.poenitz@mathematik.tu-chemnitz.de>]

On Tue, Nov 12, 2013 at 03:25:04PM +0400, Joel Brobecker wrote:
> [sorry for the duplicate, Tom, mishandling of the --to= send-email option]
> 
> Hi Tom,
> 
> > We could add a way to check for specific commands.  Then new commands
> > would never need to be added to the feature list.
> 
> What do you think of the following?
> 
> This patch adds a new GDB/MI command meant for graphical frontends
> trying to determine whether a given GDB/MI command exists or not.
> 
> Examples:
> 
>     -info-gdb-mi-command unsupported-command
>     ^done,command={exists="false"}
>     (gdb)
>     -info-gdb-mi-command symbol-list-lines
>     ^done,command={exists="true"}
>     (gdb)

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".

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

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.

Andre'