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 14:38:42 +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> <52861143 dot 3030408 at redhat dot com> <20131115123905 dot GW3481 at adacore dot com>
On 11/15/2013 12:39 PM, Joel Brobecker wrote:
>> 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.
>
> I think the intent was not to provide a probing mechanism, but
> rather to provide an approach where the FE just fires the command
> when it needs to, and then fallback on a CLI-based approach if
> detecting an 'unknown-command' error.
Yeah. Just thinking about how we'd cover all bases if we took
only one approach.
> But, on the other hand, I am thinking that some FEs might still
> want to probe ahead of time, for instance if they do not wish to
> provide a fallback mechanism (thus disabling the relevant parts
> of the GUI ahead of time);
Right, that's the reasoning I usually throw around too.
It's the same reasoning we probe things in the RSP upfront
with qSupported. I now notice that the -list-features docu
doesn't talk about that explicitly, but it could be nice to
suggest it.
> or even if it is easier programatically
> for them to probe, instead of having to handle this specific error.
>>> 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. :-)
>
> I don't have infinite amount of time, but the first 2 (new GDB/MI
> command and new ^error for unknown commands) are fairly small tasks,
> so I'm happy sending patches for both. That way, we get the best
> of both worlds, without must cost, I think, in terms of extra
> maintenance, since both patches would be pretty small, and localized.
That sounds good to me.
> For invalid usage, I could add that to my list, but that'll have
> to be next year... (/me wishes I would say that on Dec 31st...)
:-)
--
Pedro Alves