Re: MI: frozen variable objects

Frédéric Riss
2006-11-16T21:36:22Z

Le jeudi 16 novembre 2006 Ã  21:50 +0300, Vladimir Prus a Ã©crit :
> Frederic RISS wrote:
> > The interesting part seems to be the one that hasn't been submited yet
> > about GDB auto-freezing some values due to archtectural requirements.
> > The debugger has architectural knowledge and it shouldn't be necessary
> > to duplicate it in the GUI.
> [...]
> Since GUI typically rely to -var-update to read and report which values have
> changed, it's best to change -var-update not to implicitly read
> read-sensitive values. Doing this in GUI requires that GUI never
> issues -var-update for a variable object that contains read-sensitive
> children. That would be quite a drastic change in GUI architecture.
>
> With frozen variable object as implemented in the patch, GUI need only
> localized straight-forward changes.

First, note that I don't argue against adding support to the varobjs for
``frozen values'', even if that's what my mail sounded like :-).

I gathered from your first mail that the ultimate goal is to add support
in GDB for 'read-sensitive' data. That support shouldn't be limited to
MI varobjs as Daniel pointed out. To get this support for the CLI,
you'll certainly need low-level changes in GDB's value handling.

If the above is right, then the low-level changes will prevent the
varobj layer from fetching the data, and you kinda get the result you
wanted. You'd just need to make sure that the data gets fetched when
requested explicitly and to report the not-fetched-because-sensitive
varobj state.

Of course that would only work for read-sensitive data and wouldn't
allow the GUI to freeze others values. If you believe this additional
functionality would be useful to frontends, I think your opinion as a
KDevelop developer is worth listening to :-)

Fred.