RE: -var-update using formatted value

Marc Khouzam wrote:

> Sorry for the slow reply, but I wanted to think this
through.
> 
> First, about the patch
>  
>> +  if (varobj_value_is_changeable_p (var)
>> +      && var->value &&
!value_lazy (var->value))
>> +    {
>> +      free (var->print_value);
>> +      var->print_value = value_get_print_value
(var->value,
>> var->format);
>> +    }
>> +
>>    return var->format;
>>  }
> 
> I see that other places which free print_value use
xfree instead of free.
> Not sure if that matters.

xfree is supposed to be happy about deleting NULL pointers,
and should be used
everywhere. I'll fix that.

> Also, do we know for sure that print_value is not
NULL?

Yes, it should be not NULL, in light of the condition in if.
print_value is what we
use for printing variable object, and the condition makes
sure that this is actually
leaf variable object for which we should the real value, and
that we have value
to show.

> 
> I personally think this patch would improve the
behavior of varObjects so
> you have my vote (if my vote counts for anything ).
> 
>> > If I have a varObject displaying 0x1 in hex
and then I want to show the
>> > value in binary, I will need to go to the
target.
>> 
>> No. GDB keeps the raw value inside the variable
object, and changing
>> format only changed the way gdb converts that raw
value into string.
> 
> Sorry, I use 'target' to mean GDB.  For embedded
systems, we want to
> reduce the communication with GDB to a minimum, because
GDB itself is
> running on a potentially slow processor, with a small
bandwidth connection
> to the front-end. That is why I am trying to cache all
values.

I have two observations:

1. Generally, it's best to run gdb on the same system where
you run IDE,
and have it talk to remote stub on the target system. 

2. Even if you run gdb on target, changing varobj format is
very fast,
so I'm not sure caching formats is an important thing to do.
Did you
actually run into a case where the performance of changing
format is
unacceptable?

> I thought this idea would fit quite well with the
philosophy of variable
> objects. The documentation describing variable objects
says the following:
> 
> "A front-end does not need to read the values of
all variable objects each
> time the program stops. Instead, MI provides an update
command that lists
> all variable objects whose values has changed since the
last update
> operation. This considerably reduces the amount of data
that must be
> transferred to the front-end."
> 
> With the goal of "reducing the amount of data
transferred to the
> front-end", I thought it would make sense that I
would cache the value of
> every format I have previously requested for a variable
object.
> 
> I guess the problem is that GDB makes the assumption
that the front-end
> only cares about the last value retrieved by
evaluate-expression. Although
> this is sometimes the case, other times it is not.
> 
> To solve this in GDB:
> Since both use cases are valid (at least to me), the
only way I can think
> to solve this is
> to have an extra flag to var-update.  Something like
[--content-changed |
> --displayed-value-changed] It would be a separate flag
than the
> --no-values one. The front-end could then decide which
behavior it wants.
> It's not pretty but that is all I got.
> I know submitting a patch is the proper thing to do,
but I didn't think
> this idea was going to be accepted easily, so I'm
suggesting it first.
> 
> To solve this in the front-end:
> I originally thought I could always use the natural
format before doing a
> var-update, but it is not that simple since I have to
use the natural
> format for the root but also for all of the children
> of that root.  So my choices are:
> 1- don't cache (this causes the most increase in
front-end-to-GDB
> communication) 
> 2- when changing the format of a varObject and getting
the 
> value, immediately set it back to natural
>        (this will keep all varObjects, roots and
children, at natural)
> 3- before doing a -var-update on the root, set the root
AND all its
> children to natural
> 4- creating a variable object for each format.  This
turns out not to be
> efficient (if I understood
>       correctly) because each of the five varObjects
will need to be
>       var-updated and will need to go read the raw
value in memory,
>       instead of doing this once.
> 
> Solutions 2 or 3 are my best choices I believe.  But it
would be nice to
> have GDB support this.

Yeah, (4) is non-starter. (1) seems actually good for me. If
you disagree,
I'm not actually sure why (2) or (3) are necessary. Here's a
possible solution:

0. Apply my patch 
1. If a user changes format, use -var-set-format +
-var-evaluate-expression, and
cache the value.
2. After step, do -var-update. With my patch, this will
compare the formatted value
(recomputed after -var-set-format) with the new formatted
value. 
3. If a variable is reported as changed, clear all cached
formats for it.

The only case where it won't work is your example of
floating variables -- when you
have float and changed the format to integer, then change of
value from 1.1 to 1.2
won't be detected.

I'm not sure if that's a problem. Clearly, this will make it
hard for you to clear
cached values in other formats, like hex. But I'm somehow
not comfortable about
'var-update --content-changed'. In particular, if you've
changed format for a float
value to int, -var-update will mention that var whenever the
float value changed,
and I'm not sure what kind of extra operations frontends
will do as result.

- Volodya





- Volodya