Re: -var-update using formatted value

Marc Khouzam wrote:

> Hello,
> 
> I've been using varObject for a three or four months
now and I noticed
> something weird with -var-update. -var-update is
supposed to show
> variables that have changed since the last -var-udpate,
correct? It does
> not seem to work in this case:
...
> As you might guess, the reason for this is that the
binary value of var1
> (11 in binary) when doing -var-udpate is the same as
the natural value of
> var1 (11 in decimal) of the previous -var-udpate
(var-create in this
> case.)
> 
> I believe this behaviour was introduced in version 1.75
of varobj.c in
> install_new_value(), where instead of comparing value
contents, it now
> compares printed values. I'm sure there was a good
reason to compare
> printed values, but was this side-effect known?

I don't think this side-effect is known, at least it was not
discussed.
I think this is actually a bug -- we should update stored 
value when changing format. Nick, what do you think?

> Another issue with comparing printed values in
-var-update is that if a
> front-end wants to know if a variable object memory
-really- changed, it
> should perform the -var-udpate using the same format
every time, or else
> var-update will show a change although it is just the
format that changed.
> But maybe that is what was meant for -var-update to
do?

Why do you need "is it really changed" query?

- Volodya

> Why do you need "is it really changed"
query?

I'm working on the Eclipse front-end to GDB for DSDP/DSF.
It offers the ability to optionally show all formats of a
variable object (binary, decimal, etc)
To do this, we use -var-set-format.  And to avoid having to
repeatedly query GDB for all formatted
values of a varObject, we buffer all of them in the
frontend.  We only query for those values again
if the varObject has changed.

The problem is that when it is time to do a -var-update
(when the program stops), the varObject may not
be set to the same format as at the time of the previous
var-update.  And in that case,
-var-update will indicate a change in the value, which will
cause the front-end to unnecessarily
clear its value-cache, and ask GDB again for each value.

What I originally thought was that -var-udpate will notify
the front-end if the value 'really' changed.
But since it is not the case, to work around it, I do a
var-set-format to natural before each var-update.  
But it seems like a bit of a hack.

I was trying to understand why the new behaviour for
var-udpate, but I haven't figured out why
a front-end would benefit from having -var-update indicate
that
a variable object has changed if only its printed value is
different but not its actual content.

Thanks

Marc

 > I was trying to understand why the new behaviour for
var-udpate, but I
 > haven't figured out why a front-end would benefit from
having -var-update
 > indicate that a variable object has changed if only
its printed value is
 > different but not its actual content.

My logic for making the change was that changes in string
values were only
detected if their first character changed.  For example the
change
"GNU" to GDB":

  strcpy (fred, "GNU");
  strcpy (fred, "GDB");

$4 = 0x804a018 "GNU"
$5 = 0x804a018 "GDB"

did not get picked up by -var-update.

Clearly I didn't consider your case.  I notice that:

(gdb) p 11
$1 = 11
(gdb) p/x 11
$2 = 0xb
(gdb) p/o 11
$3 = 013
(gdb) p/t 11
$6 = 1011

hexadecimal and octal outputs are distinguished by a prefix
but the binary
output isn't.

In Eclipse how does the user know if he is looking at a
binary or decimal
value?

I guess there's no accepted convention for binary numbers,
but would it be
sensible for GDB to prefix their output in some way? ,
e.g.,

(gdb) p/t 11
$6 = b1011

-- 
Nick                                           http://www.inet.net.n
z/~nickrob

Nick Roberts <nickrobsnap.net.nz> writes:

> I guess there's no accepted convention for binary
numbers, but would it be
> sensible for GDB to prefix their output in some way? ,
e.g.,
>
> (gdb) p/t 11
> $6 = b1011

It should begin with a digit, otherwise it could be mistaken
for an
ordinary identifier.  0b is a often used prefix.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwabsuse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg,
Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5
214B 8276 4ED5
"And now for something completely different."

On Fri, Jan 11, 2008 at 11:53:04PM +0100, Andreas Schwab
wrote:
> It should begin with a digit, otherwise it could be
mistaken for an
> ordinary identifier.  0b is a often used prefix.

That's unambiguous with other supported number formats and
valid C
tokens, I believe.  If I'm right, it would be nice to be
able to type
binary numbers in GDB.

-- 
Daniel Jacobowitz
CodeSourcery

Daniel Jacobowitz writes:
 > On Fri, Jan 11, 2008 at 11:53:04PM +0100, Andreas
Schwab wrote:
 > > It should begin with a digit, otherwise it could
be mistaken for an
 > > ordinary identifier.  0b is a often used prefix.
 > 
 > That's unambiguous with other supported number formats
and valid C
 > tokens, I believe.  If I'm right, it would be nice to
be able to type
 > binary numbers in GDB.

I don't understand the second sentence.

-- 
Nick                                           http://www.inet.net.n
z/~nickrob

On Sat, Jan 12, 2008 at 12:39:49PM +1300, Nick Roberts
wrote:
> Daniel Jacobowitz writes:
>  > On Fri, Jan 11, 2008 at 11:53:04PM +0100, Andreas
Schwab wrote:
>  > > It should begin with a digit, otherwise it
could be mistaken for an
>  > > ordinary identifier.  0b is a often used
prefix.
>  > 
>  > That's unambiguous with other supported number
formats and valid C
>  > tokens, I believe.  If I'm right, it would be
nice to be able to type
>  > binary numbers in GDB.
> 
> I don't understand the second sentence.

I was suggesting:

(gdb) print 0b1101
$1 = 13

-- 
Daniel Jacobowitz
CodeSourcery

> My logic for making the change was that changes in
string values were only
> detected if their first character changed.  For example
the change
> "GNU" to GDB":
>  strcpy (fred, "GNU");
>  strcpy (fred, "GDB");
>
> $4 = 0x804a018 "GNU"
> $5 = 0x804a018 "GDB"

Good point.  I wouldn't have thought of that.

> In Eclipse how does the user know if he is looking at a
binary or decimal value?

In the CDT, they use 0b as a prefix (e.g., 0b1101).
And as Daniel mentions:  "it would be nice to be able
to type binary numbers in GDB."
Currently (to my knowledge) there is no way to assign a
binary value to a variable object.
It would be nice to be able to do
-var-assign var1 0b1011
So I like the idea of GDB supporting the 0b prefix.

Independently of that though, after thinking about the
problem some more, I believe there
are other issues with the current comparison for
var-update.

For example, in your example of strings changing from 
natural value: 0x804a018 "GNU" to
natural value: 0x804a018 "GDB"
If the variable object tracking this has its format set to
anything else than natural,
the actual string is not printed and the value seems to stay
the same so
-var-update will not detect the change in value.

Another example is the case of a double changing from value
1.1 to 1.2
If the variable object tracking this has its format set to
anything else than natural,
both 1.1 and 1.2 values are truncated to 1 or 0x1 etc, and
-var-update will again
miss the change in value.

So I'm thinking that it is a good idea to use the printed
value to do the comparison
for var-update, but that it should always use the natural
format to do this.

My concern was if there is a type that would have the same
value in natural format map to
two different values for some other format.  I was
originally worried about boolean,
which could show 'true' for anything different than 0, but I
noticed that GDB will
always show 1 or 0x1 etc for a boolean that is anything but
0; so I think this is also OK.

But of course, there may be other details I am not aware
of.

Always using the natural format to do the var-update
comparison would also
prevent -var-update from showing a change after the use of
-var-set-format
when the program did not actually advance, and the variable
did not actually change.

Marc

On Fri, Jan 11, 2008 at 10:41:19PM -0500, Marc Khouzam
wrote:
> For example, in your example of strings changing from 
> natural value: 0x804a018 "GNU" to
> natural value: 0x804a018 "GDB"
> If the variable object tracking this has its format set
to anything else than natural,
> the actual string is not printed and the value seems to
stay the same so
> -var-update will not detect the change in value.

That is deliberate.  I reread your message, and I still
can't see a
good reason for -var-update to report a changed variable if
-var-evaluate-expression is going to continue to display it
the same
way, i.e. as if no update has occurred.  If you're worried
about
multiple formats, maybe you should keep a varobj for each
instead of
switching one around?

-- 
Daniel Jacobowitz
CodeSourcery

> > For example, in your example of strings changing
from 
> > natural value: 0x804a018 "GNU" to
> > natural value: 0x804a018 "GDB"
> > If the variable object tracking this has its
format set to anything else than natural,
> > the actual string is not printed and the value
seems to stay the same so
> > -var-update will not detect the change in value.
> 
> That is deliberate.  I reread your message, and I still
can't see a
> good reason for -var-update to report a changed
variable if
> -var-evaluate-expression is going to continue to
display it the same
> way, i.e. as if no update has occurred.  If you're
worried about
> multiple formats, maybe you should keep a varobj for
each instead of
> switching one around?

I had assumed var-update to be an indication of when the
actual content of a variable
has changed.  Although, truth be told, the documentation is
clear that var-update will
trigger only if -var-evaluate-expression changed (for the
current format.) 
And I do see your point for this logic.

You are right that my issue is with multiple formats and
your suggestions of different
variable objects would work fine.
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.  This use-case
requires a var-update
that will indicate if a value has changed in any format, not
just the current one, so as
to know to invalidate the cache.
But I believe I can achieve this by setting the format to
natural before every -var-update,
which I have to do anyway until the -var-update fix for
binary numbers and floats
(please see other bug description below) is available.

For the sake of completeness, let me just point out that the
current var-update implementation
can often show a change when var-evaluate-expression still
displays the same thing.  This is
because the stored 'print_value' is not updated with each
-var-evaluate-expression request
e.g.,
    int z = 0xb;

    -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 because it compares it to 11 and not 0xb
    -var-evaluate-expression var1 => Oxb
    
but as I said, I'm only mentioning this for the sake of
completeness, I personally don't think
it is a big deal.

However, I do want to point to another example of the bug
that originated this discussion, which
will -not- be fixed by using the 0b prefix for binary.
I noticed that GDB prints floating point numbers such as
"1.0" as "1".  This can cause the same
problem as the binary example.

int main() {
    double d = 1.99; 
    int a = 0;       // line 3
    d = 1.0;
}

program stopped on line 3

-var-create d * d
^done,name="d",numchild="0",value="
1.99",type="double"
(gdb) 
-var-set-format d dec
^done,format="decimal"
(gdb) 
-var-evaluate-expression d
^done,value="1"
(gdb) 
next
^done
(gdb) 
-var-update d
^done,changelist=[{name="d",in_scope="true&qu
ot;,type_changed="false"}]  => superfluous
(gdb) 
-var-evaluate-expression d
^done,value="1"
(gdb) 
-var-set-format d nat
^done,format="natural"
(gdb) 
-var-evaluate-expression d
^done,value="1.99"
(gdb) 
next
^done
(gdb) 
-var-update d
^done,changelist=[]       => missing
(gdb) 
-var-evaluate-expression d
^done,value="1"


The same type of fix as the 0b prefix for binary numbers can
be used here, where
floats should always show the decimal point even if followed
by only a 0.
"1.0" cannot be shown as "1" in natural
but always as "1.0".

Again, side-effects of such a solution are unknown to me.

Marc