This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA 1/2] New GDB/MI command "-info-gdb-mi-command"

> From: Joel Brobecker <>
> Date: Mon, 18 Nov 2013 21:11:58 +0400
> Regarding some questions Eli had:
>   | > +(the leading dash (@code{-}) in the command name should be omitted).
>   | Is this wise?  How about if we support both with and without the dash?
> I now think that it was indeed the correct choice.  Not only does it
> facilitate implementation (but only marginally), it also is consistent
> with the current output.  For instance, notice how GDB names the command
> in the following error message:
>     -unsupported
>     ^error,msg="Undefined MI command: unsupported"
>                                       ^^^^^^^^^^^
>                                     (no leading dash)

Your example shows _output_ from MI.  By contrast, we are talking
about _input_.  When I send commands to MI, I cannot omit the leading
dash, so it can be very natural to consider it part of the command.

We don't have to advertise that we support the dash, 

> Also, looking at the grammar, the leading dash isn't listed
> as part of what they call the "operation"

IMO, this line of reasoning makes little sense to users.  Grammars are
for programs, not for people.

> --- a/gdb/NEWS
> +++ b/gdb/NEWS
> @@ -153,6 +153,9 @@ show startup-with-shell
>    ** All MI commands now accept an optional "--language" option.
> +  ** The new command -info-gdb-mi-command allows the user to determine
> +     whether a GDB/MI command is supported or not.
> +

OK for this part.

> +Here is an example where the @sc{gdb/mi} command does not exist:
> +
> +@smallexample
> +-info-gdb-mi-command unsupported-command
> +^done,command=@{exists="false"@}
> +@end smallexample
> +
> +And here is an example where the @sc{gdb/mi} command is known
> +to the debugger:

You want @noindent before "And here".

The documentation parts are OK with that change.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]