This is the mail archive of the
gdb-patches@sourceware.org
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: Tom Tromey <tromey at redhat dot com>, André Pönitz <andre dot poenitz at mathematik dot tu-chemnitz dot de>, gdb-patches at sourceware dot org
- Date: Fri, 15 Nov 2013 12:19:15 +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> <52851A04 dot 6040004 at redhat dot com> <52851E57 dot 30103 at redhat dot com> <87iovuwx7l dot fsf at fleche dot redhat dot com> <20131115033021 dot GT3481 at adacore dot com>
On 11/15/2013 03:30 AM, Joel Brobecker wrote:
>> Pedro> Just a POC. Of course, we'd have to go audit all MI "error" calls.
>>
>> It seems like a reasonable idea to me.
>
> The idea of a specific and documented error code seems much more robust
> to me.
>
> Regarding invalid switches, we may have to extend the current proposal
> to allow the command to specific what in the usage caused problem?
Not sure about that. Sounds more complicated than it's worth it.
> In my proposal, it was easy to extend by adding a "feature=[...]"
> list to the output. Or maybe that's overkill? Or use list-features
> for that instead?
As list-features already exists, and works just as well, that might
indeed be overkill. Or put another way, is there a use case that
list-features doesn't cover, or something about "feature=[]"
that'd make ours and frontend writers' lives easier? Just like with
list-features, we'd always have to manually take care of listing the
new command feature in "features=[]", so on our end it doesn't seem
to buy anything.
IOW, thinking in terms of KISS seems to suggest sticking with
list-features.
> I'd like us to decide to something I can go and implement. Either way,
> I think we can start by concentrating with the initial goal, which is
> to determine whether a command exists or not.
Yeah. I have no problem with your proposal. There's actually one
case where it works, and '^error,code="unknown-command"' does not,
which is when a command works and has effects without options. In such
cases, you can't probe for the command's existence without causing
the (side) effects.
> People seem to have reacted
> more positively to the idea of try-and-fallback approach, shall we go
> with Pedro's idea (without the "invalid switch"/"usage" part)?
If I had infinite time, I'd go for all of the above. Command to
probe existence of commands, and make ^error indicate both
unknown command, and bad usage. :-)
--
Pedro Alves