Re: [Patch] Fix for -var-update to use natural format to compare

[Vladimir Prus <vladimir@codesourcery.com>]

Daniel Jacobowitz wrote:

> On Tue, Jan 22, 2008 at 09:43:21AM -0500, Marc Khouzam wrote:
>> You can refer to http://sourceware.org/ml/gdb/2008-01/msg00175.html
>> where you had agreed with me :-)
> 
> That's what happens when the thread goes on too long :-)
> 
> Here's the problem, as I see it.  There are two different reasonable
> definitions of "varobj has changed".  One is that the textual
> representation has changed.  The other is that the underlying bytes
> have changed.
> 
> We used to check the underlying bytes.  This was a problem because the
> textual representation for a "char *" includes more bytes than the
> value, for C-like languages.  So, as Nick mentioned last week, we
> would not detect a change from "GNU" to "GDB" in a "char *", but we
> would display the "GNU" string in -var-evaluate-expression.
> 
> We switched to checking the string representation.  But if you're
> looking in lots of formats, then this is not enough.
> 
> We could check in all supported formats; check in the natural format;
> or go back to checking the underlying bytes.  Checking in the natural
> format is appealing because it's efficient.  But does the natural
> format always capture changes in any of the other formats?

We don't know. In particular, because we haven't yet
fully implemented Python-based custom formatting of things, so we're
not sure how that work and interact with traditional formats. 
Specifically, suppose there a command that specifies Python function
used to compute string representation of a value. In that case, 'natural'
format in the current meaning might not change while string 
representation return by the Python code changes.

I think there are actually two different problems:

1. Given single varobj that is displayed in one format, how does one
one if the value is "really changed". The answer here is that you don't
get to find that -- -var-update reports only changes in displayed
value, and since changing format is fast, nothing else is needed here.

2. If UI wishes to show varobj in several formats, how does it
figure out of *any* of formats has changed. There are two possible
solutions:

   (a) Always keep varobj (from frontnend) in natural format, and assume 
     that if natural format changes, all values possibly change. In this
     case, getting a value in different format will involve switching
     to that format and then switching back.
   (b) Allow a varobj to have a *list* formats to show. Make
     -var-update check all formats, make -var-evaluate-expression
     return all formats.

Now (a) can be done either on frontend side, or on gdb side (by making
comparisons use naturally formatted string). I suspect that the frontend
side is better here, since very few frontends regularly show same
value in several formats.

- Volodya




- Volodya