This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]