This is the mail archive of the gdb-patches@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: [Patch] Fix for -var-update to use natural format to compare


> > It modifies the variable object code to always uses the natural format to compare 
> > old and new values for the -var-update command (one line change).
> > It also renames the member print_value of varobj to natural_value.
> 
> I don't think this is an appropriate change.
> 
> -var-update is supposed to tell when the displayed value has changed.
> If the value in the current format hasn't changed, there's no need to
> refetch.  

This is assuming the frontend only displays a single value.
In DSF, we (sometimes) display all values at once.  Can be nice for the user.

> why do you want to keep track of the value in
> all formats?  And if you're actually displaying them all
> simultaneously to the user, why shouldn't they be independent varobjs?

Independent varObjects would work.  However every time the program stops
the frontend will need to issue a var-update on five objects instead of one,
and what is worse is that GDB will need to read the memory from the target
five times instead of once.  This is less efficient than the frontend
forcing GDB to use natural format (see below.)

You can refer to http://sourceware.org/ml/gdb/2008-01/msg00175.html
where you had agreed with me :-)

One solution is the patch I suggested.

An alternative suggestion that would support both use cases,
was to have an extra flag to var-update.  
Something like [--content-changed | --last-display-value-changed]
It would be a separate flag than the --no-values one.
The front-end could then decide which behavior it wants. 
Although, and I can understand, adding this new flag did not seem too
popular.

To be honest, I will have to support GDB 6.7 anyway, so I will need to
work around this by myself, no matter what.  What I will do is that
every time I issue a var-set-format and an evaluate-expression,
I will follow it by another var-set-format to natural to keep all variable
objects to the natural format.  This will force GDB to use the natural
format for its var-update comparison.
I just thought that GDB would want to support frontends that display more
than one format at once.

Thanks

Marc


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