Re: MI: frozen variable objects

[Vladimir Prus <ghost@cs.msu.su>]

Frédéric Riss wrote:

> 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.

That not exactly the design we planned. The value/type level will need two
changes:

   - Some flag on type or value to indicate it's read sensitive
   - Some mechanism to allow presenting various target register, 
     scattered over address space, as a single structure

At the same time, value level is not the right level to handle presentation
of read-sensitive values or make fetch/not fetch decisions. There's just
value_fetch_lazy function -- that fetches the raw data from the target. We
can either:

   (1) make value_fetch_lazy do nothing for read-sensitive values,
   and add new value_fetch_really function that will read the value anyway,
   or
   (2) teach the clients of value_fetch_lazy to call it only when needed

Those alternatives are roughly at the same scale of complexity. Since the
printing code should look at the value to decide if it should print
"<read sensitive>" instead not-yet fetched value, it might as well avoid
calling value_fetch_lazy. And doing (1) would mean that value_fetch_lazy
no longer guarantees that the data is fully fetched, which will be
confusing.

- Volodya