This is the mail archive of the
mailing list for the GDB project.
Re: [RFC] New GDB/MI command "-info-gdb-mi-command"
- From: Pedro Alves <palves at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: André Pönitz <andre dot poenitz at mathematik dot tu-chemnitz dot de>, Tom Tromey <tromey at redhat dot com>, gdb-patches at sourceware dot org
- Date: Thu, 14 Nov 2013 18:44:20 +0000
- Subject: Re: [RFC] New GDB/MI command "-info-gdb-mi-command"
- Authentication-results: sourceware.org; auth=none
- References: <8761rzknb4 dot fsf at fleche dot redhat dot com> <1384255504-28444-1-git-send-email-brobecker at adacore dot com> <20131112205229 dot GA7068 at klara dot mpi dot htwm dot de> <20131113021514 dot GG3481 at adacore 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
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:
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.