This is the mail archive of the
mailing list for the GDB project.
Re: [RFC] Add ada-exception-catchpoints to -list-features command output.
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 12 Nov 2013 11:57:59 +0400
- Subject: Re: [RFC] Add ada-exception-catchpoints to -list-features command output.
- Authentication-results: sourceware.org; auth=none
- References: <1384076960-12339-1-git-send-email-brobecker at adacore dot com> <8761rzknb4 dot fsf at fleche dot redhat dot com>
> Joel> This patch adds an entry meant to help the frontend for those features.
> Joel> But looking at the way the -list-features command is designed, I am
> Joel> wondering whether this approach is going to scale well. As new commands
> Joel> and other new features or major bug fixes get in, it seems like the
> Joel> list is going to grow maybe a little beyond what's reasonable.
> We could add a way to check for specific commands. Then new commands
> would never need to be added to the feature list.
I like the idea. I need to think a bit about the actual API.
I was thinking something along the lines of:
The first implementation would just return one field, which would
say yay or nay. But eventually, it might be nice to add other
properties, such as maybe some kind of versioning number to help
track evolution of the command, or maybe a command-specific feature
list. The latter might be less abstract/complex and extensible enough
to fit all needs.
So, for instance (if the following is valid GDB/MI syntax):
which would tell us that the -catch-load command exists, and that
in this version of GDB, the "-c" features is supported, for instance
telling us that it's possible to add a condition to the catchpoint.
> Joel> So, although this patch proposes a new field (this is the straightforward
> Joel> approach), given that all this GDB/MI work was done within the same
> Joel> release cycle, and withing a reasonable amount of time, I think it
> Joel> would be fine for everyone to use one single field in -list-features.
> I think it is reasonable, too, provided that the MI docs note the
> details of what the feature means.
Of course. I will send a patch as soon as I have a moment.