RE: RE: -var-update using formatted value

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

[-- Attachment #1: Type: text/plain, Size: 2598 bytes --]

Marc Khouzam wrote:

> 
>> > 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.
> 
> I'm not sure what you mean.
> 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.

>> >     -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.
> 
> This one may not really be a true bug.  The real bug is is not showing a
> change
> when there is one in evaluate-expression.  In this case, it is
> superfluous... The code has a comment about var-update being an
> approximation (in the case of a double var-assign, where this can also
> happen):
> 
>   /* If the value has changed, record it, so that next -var-update can
>      report this change.  If a variable had a value of '1', we've set it
>      to '333' and then set again to '1', when -var-update will report this
>      variable as changed -- because the first assignment has set the
>      'updated' flag.  There's no need to optimize that, because return
>      value
>      of -var-update should be considered an approximation.  */
> (from varobj.c)
> 
> 
>> 1. Make -var-evaluate-expression directly return stored printed value
>> 2. Make -var-set-format recompute the stored printed value.
> 
> Sounds good.
> Although the second change would have an interesting impact; if a
> front-end sends a var-set-format but does not follow it by a
> var-evaluate-expression. The front-end would not know about the latest
> printed value, but var-update would not show a change from the last
> var-evaluate-expression (the one of the old format and that the frontend
> does know about.) But this could be considered a bug in the frontend.

True. I attach a patch that's supposed to implement this idea. No regressions,
and seems to fix your original problem.

OK to commit?

- Volodya






[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: print_value.diff --]
[-- Type: text/x-diff; name="print_value.diff", Size: 1084 bytes --]

commit 67da794ce92c9af5fc9bc22721a942af27ade3d7
Author: Vladimir Prus <vladimir@codesourcery.com>
Date:   Tue Jan 15 23:29:36 2008 +0300

    Update stored value when format changes.
    
    	* varobj.c (varobj_set_display_format): Recomputed
    	print_value.
    	(c_value_of_variable): Return print_value.

diff --git a/gdb/varobj.c b/gdb/varobj.c
index d078bef..b0eb11a 100644
--- a/gdb/varobj.c
+++ b/gdb/varobj.c
@@ -677,6 +677,13 @@ varobj_set_display_format (struct varobj *var,
       var->format = variable_default_display (var);
     }
 
+  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;
 }
 
@@ -2260,7 +2267,7 @@ c_value_of_variable (struct varobj *var)
 
 	    gdb_assert (varobj_value_is_changeable_p (var));
 	    gdb_assert (!value_lazy (var->value));
-	    return value_get_print_value (var->value, var->format);
+	    return strdup (var->print_value);
 	  }
       }
     }