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

Pedro Alves
2013-11-14T18:44:35Z

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