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: Joel Brobecker <brobecker at adacore dot com>
- To: Pedro Alves <palves at redhat 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 16:39:06 +0400
- 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>
> > 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.
OK, I think will work well enough in practice, and, really, worrying
about a few more bytes at a time was a bit of an overreaction :).
> > 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.
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.
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); 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.
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...)
--
Joel