RE: -var-update using formatted value

["Marc Khouzam" <marc dot khouzam at ericsson dot com>]

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.
Also, do we know for sure that print_value is not NULL?

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

Thanks for your continued input.

Marc