RE: -var-update using formatted value

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

Marc Khouzam wrote:

> 
>> > For example, in your example of strings changing from
>> > natural value: 0x804a018 "GNU" to
>> > natural value: 0x804a018 "GDB"
>> > If the variable object tracking this has its format set to anything
>> > else than natural, the actual string is not printed and the value seems
>> > to stay the same so -var-update will not detect the change in value.
>> 
>> That is deliberate.  I reread your message, and I still can't see a
>> good reason for -var-update to report a changed variable if
>> -var-evaluate-expression is going to continue to display it the same
>> way, i.e. as if no update has occurred.  If you're worried about
>> multiple formats, maybe you should keep a varobj for each instead of
>> switching one around?
> 
> I had assumed var-update to be an indication of when the actual content of
> a variable
> has changed.  Although, truth be told, the documentation is clear that
> var-update will trigger only if -var-evaluate-expression changed (for the
> current format.) And I do see your point for this logic.
> 
> You are right that my issue is with multiple formats and your suggestions
> of different variable objects would work fine.
> However, in my case, where we work with embedded systems and we want to
> minimize the requests to the (potentially very slow) back-end, I was
> hoping to share the same variable
> object and to cache the value of each format.

I don't understand the above. Changing format of a variable object is not
supposed to refetch if from the target, so caching string representation
on frontend side is not necessary.

> This use-case requires a 
> var-update that will indicate if a value has changed in any format, not
> just the current one, so as to know to invalidate the cache.
> But I believe I can achieve this by setting the format to natural before
> every -var-update, which I have to do anyway until the -var-update fix for
> binary numbers and floats (please see other bug description below) is
> available.
> 
> For the sake of completeness, let me just point out that the current
> var-update implementation
> can often show a change when var-evaluate-expression still displays the
> same thing.  This is because the stored 'print_value' is not updated with
> each -var-evaluate-expression request e.g.,
>     int z = 0xb;
> 
>     -var-create - * z   (print value is remembered to be 11)
>     -var-set-format var1 hex
>     -var-evaluate-expression var1 => Oxb
>     -exec-step
>     -var-update var1              => will show var1 to have changed

As I've said before, it's a bug -- -var-set-format should recompute the stored
value. 

In fact, whereas a variable object hold the formatted string, that string
appears to be not used when reporting variable value. -var-evaluate-expression
goes to c_value_of_variable eventually, and that uses value_get_print_value.

I think we need to:

1. Make -var-evaluate-expression directly return stored printed value
2. Make -var-set-format recompute the stored printed value.

Comments?

- Volodya