This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI fine-grained versioning
On Monday 18 December 2006 18:39, Bob Rossi wrote:
> On Mon, Dec 18, 2006 at 06:35:33PM +0300, Vladimir Prus wrote:
> >
> > At the moment, MI does not have any mechanism to announce supported
> > features. For example, I have a patch to add "frozen" variable objects. To support
> > such feature in a backward-compatible fashion, the frontend must know if that
> > features is supported by the given gdb binary.
> >
> > Using version number is not very reliable -- for example if you use the CVS state
> > of gdb, the version number is not yet bumped.
> >
> > Yet another approach is to "detect" presence of feature by trying some commands,
> > or by trying commands with some new options, or by constructing more contrived test
> > cases. However that's troublesome.
> >
> > How about adding new MI command that returnes list of supported fine-grained features.
> > For example:
> >
> > -list-features
> > ^done,result=["frozen_variables","info_path_expression"]
> >
> > The MI manual would contain a section listing all feature names and briefly documenting them.
>
> Great idea!
>
> There are a few gothcha's. For instance, each command can support
> several parameters, so you might want to report on that.
Yes. For example if -var-registers end up being
-var-create --registers
we'd need a feature name.
> But more
> tricky, is when a command adds an output field that the front end cares
> about. An example of this would be that the -break-list command has
> always existed, but the -break-list command added fullpath functionality
> later on it it's life. How would you handle this, if at all?
That's actually easy. If a frontend can handle the extra field locally,
then we don't need new element in -list-features. If it cannot, we need new element.
This "can" and "cannot" is determined by hacking the relevant support in KDevelop.
If an author of some other frontend wants new item in -list-features, that element
is added too. It's generally easier to add new elements to -list-features as frontend
authors request, then argue about "inherent" need to announce a specific change.
- Volodya