This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]