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

[Pedro Alves <palves at redhat dot com>]

On 11/13/2013 02:15 AM, Joel Brobecker wrote:
>> 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.

Yeah.  I think that points out that errors like "Undefined MI command:" and
"Usage:" errors are in a different class of errors from errors caused
by user input though.  The former should never ever be seen by the user.
They're "internal" gdb<->frontend errors.  We could/should tag these
differently somehow, so that the frontend doesn't have to parse a
free form string.  Like:

 "^error,msg="..."
 "^error,msg="...",code="unknown-command"
 "^error,msg="...",code="usage"

or some such.

This does not invalidate listing features in -list-features, as
it's often useful to know upfront whether some feature is supported,
so the frontend can disable parts of the GUI that won't make sense
for the current target/session.

-- 
Pedro Alves