RE: -var-update using formatted value

["Marc Khouzam" <marc.khouzam@ericsson.com>]

> > 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.  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 because it compares it to 11 and not 0xb
    -var-evaluate-expression var1 => Oxb
    
but as I said, I'm only mentioning this for the sake of completeness, I personally don't think
it is a big deal.

However, I do want to point to another example of the bug that originated this discussion, which
will -not- be fixed by using the 0b prefix for binary.
I noticed that GDB prints floating point numbers such as "1.0" as "1".  This can cause the same
problem as the binary example.

int main() {
    double d = 1.99; 
    int a = 0;       // line 3
    d = 1.0;
}

program stopped on line 3

-var-create d * d
^done,name="d",numchild="0",value="1.99",type="double"
(gdb) 
-var-set-format d dec
^done,format="decimal"
(gdb) 
-var-evaluate-expression d
^done,value="1"
(gdb) 
next
^done
(gdb) 
-var-update d
^done,changelist=[{name="d",in_scope="true",type_changed="false"}]  => superfluous
(gdb) 
-var-evaluate-expression d
^done,value="1"
(gdb) 
-var-set-format d nat
^done,format="natural"
(gdb) 
-var-evaluate-expression d
^done,value="1.99"
(gdb) 
next
^done
(gdb) 
-var-update d
^done,changelist=[]       => missing
(gdb) 
-var-evaluate-expression d
^done,value="1"


The same type of fix as the 0b prefix for binary numbers can be used here, where
floats should always show the decimal point even if followed by only a 0.
"1.0" cannot be shown as "1" in natural but always as "1.0".

Again, side-effects of such a solution are unknown to me.

Marc