-var-update using formatted value

-var-update using formatted value

[Marc Khouzam]

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:

int main() {
    int a = 11;   // line 3
    a = 3;         // line 4
}

MI commands:
-break-insert main
-exec-run
-exec-next
-var-create - * a
-var-set-format var1 bin
-var-evaluate-expression var1
-exec-next
-var-update var1
-var-evaluate-expression var1

Session (output simplified with [...])
-break-insert main
^done,...
(gdb) 
-exec-run
^running
(gdb) 
*stopped,reason="breakpoint-hit",[...],line="3"}
(gdb) 
-exec-next
^running
(gdb) 
*stopped,reason="end-stepping-range",[...]",line="4"}
(gdb) 
-var-create - * a
^done,name="var1",numchild="0",value="11",type="int"
(gdb) 
-var-set-format var1 bin
^done,format="binary"
(gdb) 
-var-evaluate-expression var1
^done,value="1011"
(gdb) 
-exec-next
^running
(gdb) 
*stopped,reason="end-stepping-range",[...],line="5"}
(gdb) 
-var-update var1
^done,changelist=[]
(gdb) 
-var-evaluate-expression var1
^done,value="11"

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?

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?

Thanks for your input.

Marc



 
Marc Khouzam
Software Designer, Methods and Tools
 
Ericsson Canada Inc
EMC/Q
8500 Decarie Blvd.
H4P 2N2, Mont-Royal, Qc, Canada
www.ericsson.comOffice: +514 345 7900 x42350
Fax: +514 345 6159
Mobile: +514 951 7191
Email: Marc.Khouzam@ericsson.com




Ce courriel est confidentiel et uniquement destiné à son ou ses destinataires. Il est défendu de le consulter, de l'utiliser, de le dévoiler ou de le diffuser sans autorisation. Si ce message vous est parvenu par erreur, merci d'en aviser l'expéditeur par retour de courrier et de le détruire sans le divulguer.  Un courriel et ses pièces jointes peut être sans autorisation corrompu, interrompu, amendé, altéré et infecté. L'entreprise ne reçoit et n'envoie de courriel qu'avec l'entente qu'elle n'est responsable d'aucune corruption, interception, modification, altération, infection ou conséquence possible.
This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.  E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

Re: -var-update using formatted value

[Vladimir Prus]

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

RE: Re: -var-update using formatted value

[Marc Khouzam]

> 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

Re: -var-update using formatted value

[Marc Khouzam]

This may be an over-simplified solution, but I think that if GDB always use the 
Natural format when storing the print value, it will fix the problem.
From looking at the varobj.c code, I believe that the only impact will be
to the -var-update output.  -var-update would no longer show variables who have
changed only due to a format change, but only those which have 'really' changed.

It is a one-line fix and I tried it successfully on the little example
that was giving a problem.
The patch is:

Index: varobj.c
===================================================================
RCS file: /cvs/src/src/gdb/varobj.c,v
retrieving revision 1.99
diff -u -r1.99 varobj.c
--- varobj.c    1 Jan 2008 22:53:13 -0000       1.99
+++ varobj.c    11 Jan 2008 19:23:48 -0000
@@ -1029,7 +1029,7 @@
      lazy -- if it is, the code above has decided that the value
      should not be fetched.  */
   if (value && !value_lazy (value))
-      print_value = value_get_print_value (value, var->format);
+      print_value = value_get_print_value (value, FORMAT_NATURAL);
 
   /* If the type is changeable, compare the old and the new values.
      If this is the initial assignment, we don't have any old value




-----Original Message-----
From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org]On
Behalf Of Marc Khouzam
Sent: Friday, January 11, 2008 1:31 PM
To: gdb@sources.redhat.com
Subject: RE: Re: -var-update using formatted value



> 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

RE: Re: -var-update using formatted value

[Nick Roberts]

 > 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.nz/~nickrob

Re: -var-update using formatted value

[Andreas Schwab]

Nick Roberts <nickrob@snap.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, schwab@suse.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."

Re: -var-update using formatted value

[Daniel Jacobowitz]

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

Re: -var-update using formatted value

[Nick Roberts]

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.nz/~nickrob

Re: -var-update using formatted value

[Daniel Jacobowitz]

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

RE: -var-update using formatted value

[Marc Khouzam]

> 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

Re: -var-update using formatted value

[Daniel Jacobowitz]

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

RE: -var-update using formatted value

[Marc Khouzam]

> > 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",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

Re: -var-update using formatted value

[Nick Roberts]

 > I was suggesting:
 > 
 > (gdb) print 0b1101
 > $1 = 13

I guess the change below to c-exp.y does that, at least for C.  But AFAIK 0b
is not a recognised prefix for C.

I was thinking of:

(gdb) print/t 13
$1 = 0b1101

and

-var-create - * i22
^done,name="var1",numchild="0",value="6",type="volatile int"
(gdb) 
-var-set-format var1 binary
^done,format="binary"
(gdb) 
-var-update --all-values var1
^done,changelist=[{name="var1",value="0b110",in_scope="true",type_changed="false"}]
(gdb) 


the change below to printcmd.c does this.  This seems to be consistent with
existing usage, e.g. in Modula-2 hexadecimals are input like 0FFH but
output in a lanuage independent way as 0xff.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

*** printcmd.c.~1.116.~	2008-01-12 11:31:27.000000000 +1300
--- printcmd.c	2008-01-14 19:23:16.000000000 +1300
*************** print_scalar_formatted (const void *vala
*** 484,489 ****
--- 484,490 ----
  	      cp--;
  	  }
  	strcpy (buf, cp);
+ 	fputs_filtered ("0b", stream);
  	fputs_filtered (buf, stream);
        }
        break;


*** c-exp.y.~1.42.~	2008-01-10 09:15:34.000000000 +1300
--- c-exp.y	2008-01-14 18:38:06.000000000 +1300
*************** parse_number (p, len, parsed_float, puti
*** 1180,1185 ****
--- 1180,1194 ----
  	  }
  	break;
  
+       case 'b':
+ 	if (len >= 3)
+ 	  {
+ 	    p += 2;
+ 	    base = 2;
+ 	    len -= 2;
+ 	  }
+ 	break;
+ 
        default:
  	base = 8;
  	break;

RE: -var-update using formatted value

[Vladimir Prus]

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

I don't understand the above. Changing format of a variable object is not
supposed to refetch if from the target, so caching string representation
on frontend side is not necessary.

> 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

As I've said before, it's a bug -- -var-set-format should recompute the stored
value. 

In fact, whereas a variable object hold the formatted string, that string
appears to be not used when reporting variable value. -var-evaluate-expression
goes to c_value_of_variable eventually, and that uses value_get_print_value.

I think we need to:

1. Make -var-evaluate-expression directly return stored printed value
2. Make -var-set-format recompute the stored printed value.

Comments?

- Volodya

RE: RE: -var-update using formatted value

[Marc Khouzam]

> > 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.
> > 
> I don't understand the above. Changing format of a variable object is not
> supposed to refetch if from the target, so caching string representation
> on frontend side is not necessary.

I'm not sure what you mean.
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.
If I cache both those values in the frontend, then I was hoping to rely
on var-update to let me know if my cache is still valid, for any formats not
just the last one I used.

> >     -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
> 
> As I've said before, it's a bug -- -var-set-format should recompute the stored
> value. 

This one may not really be a true bug.  The real bug is is not showing a change
when there is one in evaluate-expression.  In this case, it is superfluous...
The code has a comment about var-update being an approximation (in the case
of a double var-assign, where this can also happen):

  /* If the value has changed, record it, so that next -var-update can
     report this change.  If a variable had a value of '1', we've set it
     to '333' and then set again to '1', when -var-update will report this
     variable as changed -- because the first assignment has set the
     'updated' flag.  There's no need to optimize that, because return value
     of -var-update should be considered an approximation.  */
(from varobj.c)


> 1. Make -var-evaluate-expression directly return stored printed value
> 2. Make -var-set-format recompute the stored printed value.

Sounds good.
Although the second change would have an interesting impact; if a front-end 
sends a var-set-format but does not follow it by a var-evaluate-expression.
The front-end would not know about the latest printed value, but var-update
would not show a change from the last var-evaluate-expression (the one of the old
format and that the frontend does know about.)  
But this could be considered a bug in the frontend.

RE: RE: -var-update using formatted value

[Vladimir Prus]

[-- Attachment #1: Type: text/plain, Size: 2598 bytes --]

Marc Khouzam wrote:

> 
>> > 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.
>> > 
>> I don't understand the above. Changing format of a variable object is not
>> supposed to refetch if from the target, so caching string representation
>> on frontend side is not necessary.
> 
> I'm not sure what you mean.
> 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.

>> >     -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
>> 
>> As I've said before, it's a bug -- -var-set-format should recompute the
>> stored value.
> 
> This one may not really be a true bug.  The real bug is is not showing a
> change
> when there is one in evaluate-expression.  In this case, it is
> superfluous... The code has a comment about var-update being an
> approximation (in the case of a double var-assign, where this can also
> happen):
> 
>   /* If the value has changed, record it, so that next -var-update can
>      report this change.  If a variable had a value of '1', we've set it
>      to '333' and then set again to '1', when -var-update will report this
>      variable as changed -- because the first assignment has set the
>      'updated' flag.  There's no need to optimize that, because return
>      value
>      of -var-update should be considered an approximation.  */
> (from varobj.c)
> 
> 
>> 1. Make -var-evaluate-expression directly return stored printed value
>> 2. Make -var-set-format recompute the stored printed value.
> 
> Sounds good.
> Although the second change would have an interesting impact; if a
> front-end sends a var-set-format but does not follow it by a
> var-evaluate-expression. The front-end would not know about the latest
> printed value, but var-update would not show a change from the last
> var-evaluate-expression (the one of the old format and that the frontend
> does know about.) But this could be considered a bug in the frontend.

True. I attach a patch that's supposed to implement this idea. No regressions,
and seems to fix your original problem.

OK to commit?

- Volodya






[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: print_value.diff --]
[-- Type: text/x-diff; name="print_value.diff", Size: 1084 bytes --]

commit 67da794ce92c9af5fc9bc22721a942af27ade3d7
Author: Vladimir Prus <vladimir@codesourcery.com>
Date:   Tue Jan 15 23:29:36 2008 +0300

    Update stored value when format changes.
    
    	* varobj.c (varobj_set_display_format): Recomputed
    	print_value.
    	(c_value_of_variable): Return print_value.

diff --git a/gdb/varobj.c b/gdb/varobj.c
index d078bef..b0eb11a 100644
--- a/gdb/varobj.c
+++ b/gdb/varobj.c
@@ -677,6 +677,13 @@ varobj_set_display_format (struct varobj *var,
       var->format = variable_default_display (var);
     }
 
+  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;
 }
 
@@ -2260,7 +2267,7 @@ c_value_of_variable (struct varobj *var)
 
 	    gdb_assert (varobj_value_is_changeable_p (var));
 	    gdb_assert (!value_lazy (var->value));
-	    return value_get_print_value (var->value, var->format);
+	    return strdup (var->print_value);
 	  }
       }
     }

RE: -var-update using formatted value

[Marc Khouzam]

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

RE: -var-update using formatted value

[Vladimir Prus]

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

RE: RE: -var-update using formatted value

[Nick Roberts]

 >     Update stored value when format changes.
 >     
 >     	* varobj.c (varobj_set_display_format): Recomputed
 >     	print_value.
 >     	(c_value_of_variable): Return print_value.
 > 
 > diff --git a/gdb/varobj.c b/gdb/varobj.c
 > index d078bef..b0eb11a 100644
 > --- a/gdb/varobj.c
 > +++ b/gdb/varobj.c
 > @@ -677,6 +677,13 @@ varobj_set_display_format (struct varobj *var,
 >        var->format = variable_default_display (var);
 >      }
 >  
 > +  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;
 >  }
 >
 > @@ -2260,7 +2267,7 @@ c_value_of_variable (struct varobj *var)
 >  
 >  	    gdb_assert (varobj_value_is_changeable_p (var));
 >  	    gdb_assert (!value_lazy (var->value));
 > -	    return value_get_print_value (var->value, var->format);
 > +	    return strdup (var->print_value);
 >  	  }
 >        }
 >      }

I don't like this change.  If I change the format to hexadecimal, 11 -> 0xb
say, the display should change, so I would like GDB to report it through
-var-update.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

RE: -var-update using formatted value

[Nick Roberts]

 > I noticed that GDB prints floating point numbers such as "1.0" as
 > "1".

This seems to be an unfortunate consequence of the g conversion specifier.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

RE: -var-update using formatted value

[Nick Roberts]

[aside - can you please fit your messages into 80 columns]

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

Previously -var-evaluate-expression was needed because values weren't displayed
when variable objects were created (-var-create now includes the value field,
-var-list-children has the --all-values option).  Given that -var-update
provides a record of all changes, I'm not sure that -var-evaluate-expression is
necessary now.

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

Generally I don't think changing the format of already retrieved values is
expensive.

You said:

    GDB itself is running on a potentially slow
    processor, with a small bandwidth connection to the front-end.

Could you expand on that scenario?

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

They're quite intrusive changes for what seems like a very specialised case.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

RE: -var-update using formatted value

[Marc Khouzam]

I think you are referring to the code that uses "%.9g"
The format "%#.9g" could be used instead...
But trailing zeros will not be removed at all, so 1.0 will be 1.000000000 instead of 1
but this will also be true for numbers like 1.11 which would not be 1.110000000
That is probably not a good thing


-----Original Message-----
From: Nick Roberts [mailto:nickrob@snap.net.nz]
Sent: Thu 1/17/2008 7:53 PM
To: Marc Khouzam
Cc: gdb@sources.redhat.com
Subject: RE: -var-update using formatted value
 
 > I noticed that GDB prints floating point numbers such as "1.0" as
 > "1".

This seems to be an unfortunate consequence of the g conversion specifier.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

RE: -var-update using formatted value

[Marc Khouzam]

Answering two mails:

Vladimir wrote:

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

You make a good point.
I had started to blur the concept of GDB and target and I didn't pay
attention to this anymore.  Thanks for reminding me.

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

No actual measurements.
However, and I'm sorry for not letting this go, but what is the point of 
-var-update returning the list of changed variables, if it is so efficient
to go back to GDB to ask for values?  var-update might as well return nothing
and the let the front-end ask for values again.
(which is what I'll have to do if I can't cache all formats)

I thought var-update told the front-end which variables changed and more
importantly, which variables did -not- change, specifically so that the
front-end would not need to request values that did not change.
To be able to do this, the front-end must cache the value, even if it is
only in a single format.   
Why does it make sense to cache the value for one format but not for all?

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

Yes the float (and string) issue remains my last problem with the cache.
Even if this is a rare case, the cache must be right all the time,
not most of the time :-)  If not, I cannot have a cache.

Nick wrote:

> I don't like this change.  If I change the format to hexadecimal, 11 -> 0xb
> say, the display should change, so I would like GDB to report it through
> -var-update.

> Previously -var-evaluate-expression was needed because values weren't
> displayed when variable objects were created (-var-create now includes the
> value field, -var-list-children has the --all-values option).  Given that
> -var-update provides a record of all changes, I'm not sure that
> -var-evaluate-expression is necessary now.

It is starting to come together now :-)
What you are missing is for -var-set-format to have the --all-values flag.
Then, I believe you can stop using -var-evaluate-expression.  Using -var-update
instead of var-evaluate-expression or -var-set-format --all-values seems kind
of a hack...

What do you think of that?  Vladimir's patch and --all-values in set-format?
To me, it seems like the proper solution.

Marc

Re: -var-update using formatted value

[Daniel Jacobowitz]

On Fri, Jan 18, 2008 at 10:28:04AM -0500, Marc Khouzam wrote:
> However, and I'm sorry for not letting this go, but what is the point of 
> -var-update returning the list of changed variables, if it is so efficient
> to go back to GDB to ask for values?  var-update might as well return nothing
> and the let the front-end ask for values again.
> (which is what I'll have to do if I can't cache all formats)

-var-update reads values from the target to check for changes.
-var-update-expression and -var-set-format do not.  If you do not
-var-update nothing will ever appear to change.

-- 
Daniel Jacobowitz
CodeSourcery

RE: -var-update using formatted value

[Marc Khouzam]

> > However, and I'm sorry for not letting this go, but what is the point of 
> > -var-update returning the list of changed variables, if it is so efficient
> > to go back to GDB to ask for values?  var-update might as well return nothing
> > and the let the front-end ask for values again.
> > (which is what I'll have to do if I can't cache all formats)
> 
> -var-update reads values from the target to check for changes.
> -var-update-expression and -var-set-format do not.  If you do not
> -var-update nothing will ever appear to change.

I'm not questioning var-update.  It is a must after the program has resumed.
But why does var-update actually report the changed variables to the front-end?
Why not just report "done"?
If var-update tells the front-end which variables have changed, it is for the 
front-end to know which ones it should use -var-evaluate-expression on
(say --no-values is used for var-update).  The front-end then does not need
to use -var-evaluate-expression on -all- displayed variables.

In my case, since I display all formats (sometimes), I need to do 
var-evaluate-expression on every displayed variable, since var-update won't 
properly tell me which variable really changed (in the case of float and strings).

Re: -var-update using formatted value

[Daniel Jacobowitz]

On Fri, Jan 18, 2008 at 12:17:19PM -0500, Marc Khouzam wrote:
> In my case, since I display all formats (sometimes), I need to do 
> var-evaluate-expression on every displayed variable, since var-update won't 
> properly tell me which variable really changed (in the case of float and strings).

We should fix that.  Is checking in natural format the answer?  Do we
really need to check all supported formats - that could get out of
hand if we support custom formatting someday.

-- 
Daniel Jacobowitz
CodeSourcery

RE: -var-update using formatted value

[Marc Khouzam]

> > In my case, since I display all formats (sometimes), I need to do 
> > var-evaluate-expression on every displayed variable, since var-update won't 
> > properly tell me which variable really changed (in the case of float and strings).
>
> We should fix that.  Is checking in natural format the answer?  Do we
> really need to check all supported formats - that could get out of
> hand if we support custom formatting someday.

I didn't find an example where checking the natural format would not work.
But that may not mean much :-)
Boolean could have been a problem (0x1, 0x2, 0x3 etc are all "true" in natural),
but it seems that for now, GDB always shows 0x1 for true.

A safer way may be to have GDB check for content difference, as it used to do
before.  But it would also need to check the natural printed format for strings
(to detect a change from "GDB" to "GNU").

Marc

RE: -var-update using formatted value

[Nick Roberts]

 > I think you are referring to the code that uses "%.9g" The format "%#.9g"
 > could be used instead...  But trailing zeros will not be removed at all, so
 > 1.0 will be 1.000000000 instead of 1 but this will also be true for numbers
 > like 1.11 which would not be 1.110000000 That is probably not a good thing

If it's important, you could presumably print to a string first, do a regexp
match and then add a decimal point if the number did not have one.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

RE: -var-update using formatted value

[Nick Roberts]

 > > I don't like this change.  If I change the format to hexadecimal, 11 -> 0xb
 > > say, the display should change, so I would like GDB to report it through
 > > -var-update.
 > 
 > > Previously -var-evaluate-expression was needed because values weren't
 > > displayed when variable objects were created (-var-create now includes the
 > > value field, -var-list-children has the --all-values option).  Given that
 > > -var-update provides a record of all changes, I'm not sure that
 > > -var-evaluate-expression is necessary now.
 > 
 > It is starting to come together now :-) 
 > What you are missing is for -var-set-format to have the --all-values flag.
 > Then, I believe you can stop using -var-evaluate-expression.  Using
 > -var-update instead of var-evaluate-expression or -var-set-format
 > --all-values seems kind of a hack...

I don't use -var-evaluate-expression for current GDB.

 > What do you think of that?  Vladimir's patch and --all-values in set-format?
 > To me, it seems like the proper solution.

If I don't like Vladimir's patch on its own, I don't see why I should like it
with --all-values in -var-set-format.  But I'm probably missing your point.

What would "-var-set-format --all-values" return?  The value in the current
format or all formats?

When GDB stops I use "-var-update --all-values" to find out which watch
expressions have changed.  What are you proposing that I should use?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

RE: -var-update using formatted value

[Marc Khouzam]

> If it's important, you could presumably print to a string first, do a 
> regexp match and then add a decimal point if the number did not have one.

That's pretty good.
We'll see if it is important from the rest of the thread :-)

RE: -var-update using formatted value

[Marc Khouzam]

> If I change the format to hexadecimal, 11 -> 0xb say, the display should
> change, so I would like GDB to report it through -var-update.

Can you elaborate?  When do you call var-update in this case?  Is it right after
the var-set-format?

> I don't use -var-evaluate-expression for current GDB.

So how to you display a value in a different format (say hex)? You must
be calling -var-update right away after the set-format.  That is why I thought 
"-var-set-format --all-values var1 hex" 
would return the value in hex (or whatever format specified).
I'd use this too, as I wouldn't need to call evaluate-expression after
var-set-format.

Then, you could say var-evaluate-expression is superfluous (I think).

RE: -var-update using formatted value

[Nick Roberts]

 > > If I change the format to hexadecimal, 11 -> 0xb say, the display should
 > > change, so I would like GDB to report it through -var-update.
 > 
 > Can you elaborate?  When do you call var-update in this case?  Is it right
 > after the var-set-format?

Yes.  Emacs sends commands to GDB behind the user's back to update the display
every time the user initiates a GDB command himself.

You can see what Emacs 22.1 does quite easily.  You probably don't want to look
through thousands of lines of lisp code (gdb-ui.el) but you can just set
gdb-enable-debug to t and look at the value of gdb-debug-log after issuing some
commands to GDB in a session in Emacs (M-x gdb) so see the transactions.

In fact, I'd be interested to know how well (badly?) GDB in Emacs performs
in an embedded environment.

 > > I don't use -var-evaluate-expression for current GDB.
 > 
 > So how to you display a value in a different format (say hex)? You must be
 > calling -var-update right away after the set-format.  That is why I thought
 > "-var-set-format --all-values var1 hex" would return the value in hex (or
 > whatever format specified).  I'd use this too, as I wouldn't need to call
 > evaluate-expression after var-set-format.

"-var-update --all-values" returns the value in hex so currently I don't think
you need it in the output of "-var-set-format".  Previously, when the contents
were compared, I did submit a patch to add the value field to the output of
"-var-set-format" but it was never incorporated.  Note that, as stated in the
manual, new fields may be added to existing commands, so your existinng
frontend should be able to handle the parsing of these possible extra fields
and adding an option "--all-values" isn't necessary.  In fact, it's probably
undesirable because the frontend would have to test for the availability of
this option, rather than just the presence of the field in the output.

 > Then, you could say var-evaluate-expression is superfluous (I think).

I think I already have!

-- 
Nick                                           http://www.inet.net.nz/~nickrob

RE: -var-update using formatted value

[Marc Khouzam]

Nick wrote:

> "-var-update --all-values" returns the value in hex so currently I don't think
> you need it in the output of "-var-set-format".  

Can I get a clarification on what var-update is -really- supposed to do?

I say var-update should show changes when they occur on the target
and that var-update should only be used once per varObject when a program stops.

You say var-update should show changes when they affect the display, independently
of if they were caused by a content change in the target or a format change in GDB.
In that case, var-update is used multiple times without the program having stepped.

What is var-update really meant to do?

RE: -var-update using formatted value

[Nick Roberts]

 > I say var-update should show changes when they occur on the target and that
 > var-update should only be used once per varObject when a program stops.

If the user assigns a new value to a variable the frontend needs to update to
this without waiting for program execution.

 > You say var-update should show changes when they affect the display,
 > independently of if they were caused by a content change in the target or a
 > format change in GDB.  In that case, var-update is used multiple times
 > without the program having stepped.

I think it needs to be used after every user command for the reason above.  I
guess this could be expensive for a remote target.

 > What is var-update really meant to do?

It's meant to do whatever we find most convenient but I don't know when you
would wish to display floats as hexadecimals, or why you would want to cache a
value in multiple formats.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: -var-update using formatted value

[Vladimir Prus]

On Friday 18 January 2008 02:10:12 Nick Roberts wrote:
>  >     Update stored value when format changes.
>  >     
>  >     	* varobj.c (varobj_set_display_format): Recomputed
>  >     	print_value.
>  >     	(c_value_of_variable): Return print_value.
>  > 
>  > diff --git a/gdb/varobj.c b/gdb/varobj.c
>  > index d078bef..b0eb11a 100644
>  > --- a/gdb/varobj.c
>  > +++ b/gdb/varobj.c
>  > @@ -677,6 +677,13 @@ varobj_set_display_format (struct varobj *var,
>  >        var->format = variable_default_display (var);
>  >      }
>  >  
>  > +  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;
>  >  }
>  >
>  > @@ -2260,7 +2267,7 @@ c_value_of_variable (struct varobj *var)
>  >  
>  >  	    gdb_assert (varobj_value_is_changeable_p (var));
>  >  	    gdb_assert (!value_lazy (var->value));
>  > -	    return value_get_print_value (var->value, var->format);
>  > +	    return strdup (var->print_value);
>  >  	  }
>  >        }
>  >      }
> 
> I don't like this change.  If I change the format to hexadecimal, 11 -> 0xb
> say, the display should change, so I would like GDB to report it through
> -var-update.

Why? It seems to me that if user does "change format" in UI, then UI should:

  1. Change format
  2. Display the value shown according to the new format

I cannot imagine any usecase where the frontend would:

 1. Change format
 2. Step program
 3. Issue -var-update

- Volodya


> 

RE: -var-update using formatted value

[Vladimir Prus]

Marc Khouzam wrote:

> 
> Nick wrote:
> 
>> "-var-update --all-values" returns the value in hex so currently I don't
>> think you need it in the output of "-var-set-format".
> 
> Can I get a clarification on what var-update is -really- supposed to do?
> 
> I say var-update should show changes when they occur on the target
> and that var-update should only be used once per varObject when a program
> stops.
> 
> You say var-update should show changes when they affect the display,
> independently of if they were caused by a content change in the target or
> a format change in GDB. In that case, var-update is used multiple times
> without the program having stepped.
> 
> What is var-update really meant to do?

I probably need to start with some background -- if that sound obvious,
just skip it. There are two important point of interactions between frontend
and GDB. First is updating all of UI state after stop. This means passing
really lots of information, so ideally (and MI is not there yet), we want
gdb to basically report to frontend, in one big response, everything that frontend
cares about that might have changed -- changes in values of variables, variables than
went into scope and left it, new threads, everything.
Second interaction point is explicit user command -- like evaluating a given
expression, setting a breakpoint, or changing variable format. The amount of data
here is limited, and we don't need to optimize this very hard.

So, -var-update reports to frontend all variables that have changed since
last resume. You can query each variable individually, but you might have 100
variables easily, and that will really get slow.

Does this make sense?

- Volodya

Re: -var-update using formatted value

[Nick Roberts]

 > > I don't like this change.  If I change the format to hexadecimal, 11 -> 0xb
 > > say, the display should change, so I would like GDB to report it through
 > > -var-update.
 > 
 > Why? It seems to me that if user does "change format" in UI, then UI should:
 > 
 >   1. Change format
 >   2. Display the value shown according to the new format
 
In this case, GDB needs to print the value of the new format.  I did submit a
patch to do this in the thread:

http://sourceware.org/ml/gdb-patches/2006-05/msg00008.html

but it never got approved.  I've now configured Emacs (but can revert) for
current behaviour.


 > I cannot imagine any usecase where the frontend would:
 > 
 >  1. Change format
 >  2. Step program
 >  3. Issue -var-update

I'm not sure what point you're making here.  Debugging GDB, has variables which
contain addresses which are not pointers (so the natural format is decimal),
e.g., stack_addr, code_addr components of frames.  It makes sense here to:

1.  Change format to hexadecimal
2.  Step GDB
3.  Issue -var-update to see if these values have changed.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: -var-update using formatted value

[Vladimir Prus]

On Sunday 20 January 2008 01:01:29 Nick Roberts wrote:
>  > > I don't like this change.  If I change the format to hexadecimal, 11 -> 0xb
>  > > say, the display should change, so I would like GDB to report it through
>  > > -var-update.
>  > 
>  > Why? It seems to me that if user does "change format" in UI, then UI should:
>  > 
>  >   1. Change format
>  >   2. Display the value shown according to the new format
>  
> In this case, GDB needs to print the value of the new format.  I did submit a
> patch to do this in the thread:
> 
> http://sourceware.org/ml/gdb-patches/2006-05/msg00008.html
> 
> but it never got approved.  I've now configured Emacs (but can revert) for
> current behaviour.
> 
> 
>  > I cannot imagine any usecase where the frontend would:
>  > 
>  >  1. Change format
>  >  2. Step program
>  >  3. Issue -var-update
> 
> I'm not sure what point you're making here.  Debugging GDB, has variables which
> contain addresses which are not pointers (so the natural format is decimal),
> e.g., stack_addr, code_addr components of frames.  It makes sense here to:
> 
> 1.  Change format to hexadecimal
> 2.  Step GDB
> 3.  Issue -var-update to see if these values have changed.

What UI-level command does this? And why, after you change format, 
you don't read/display the value in new format?

- Volodya

Re: -var-update using formatted value

[Nick Roberts]

 > >  > I cannot imagine any usecase where the frontend would:
 > >  > 
 > >  >  1. Change format
 > >  >  2. Step program
 > >  >  3. Issue -var-update
 > > 
 > > I'm not sure what point you're making here.  Debugging GDB, has variables
 > > which contain addresses which are not pointers (so the natural format is
 > > decimal), e.g., stack_addr, code_addr components of frames.  It makes
 > > sense here to:
 > > 
 > > 1.  Change format to hexadecimal
 > > 2.  Step GDB
 > > 3.  Issue -var-update to see if these values have changed.
 > 
 > What UI-level command does this? And why, after you change format, 
 > you don't read/display the value in new format?

Creating a watch expression (in the speedbar, in the case of Emacs) for a frame
related structure would do this.  Yes, currently you would need to do
-var-update after 1..

Anyway, I withdraw my objection to your patch, if the patch (or similar) in the
thread I mentioned (http://sourceware.org/ml/gdb-patches/2006-05/msg00008.html)
is also approved.  So there appears to be some consensus here.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: -var-update using formatted value

[Vladimir Prus]

On Sunday 20 January 2008 23:15:26 Nick Roberts wrote:
>  > >  > I cannot imagine any usecase where the frontend would:
>  > >  > 
>  > >  >  1. Change format
>  > >  >  2. Step program
>  > >  >  3. Issue -var-update
>  > > 
>  > > I'm not sure what point you're making here.  Debugging GDB, has variables
>  > > which contain addresses which are not pointers (so the natural format is
>  > > decimal), e.g., stack_addr, code_addr components of frames.  It makes
>  > > sense here to:
>  > > 
>  > > 1.  Change format to hexadecimal
>  > > 2.  Step GDB
>  > > 3.  Issue -var-update to see if these values have changed.
>  > 
>  > What UI-level command does this? And why, after you change format, 
>  > you don't read/display the value in new format?
> 
> Creating a watch expression (in the speedbar, in the case of Emacs) for a frame
> related structure would do this.  Yes, currently you would need to do
> -var-update after 1..
> 
> Anyway, I withdraw my objection to your patch, if the patch (or similar) in the
> thread I mentioned (http://sourceware.org/ml/gdb-patches/2006-05/msg00008.html)
> is also approved.  So there appears to be some consensus here.

FWIW, I agree that the patch in
http://sourceware.org/ml/gdb-patches/2006-05/msg00008.html
is good, as it removes the need to do -var-evaluate-expression 
or -var-update after setting variable's format.

- Volodya

RE: -var-update using formatted value

[Marc Khouzam]

> > Anyway, I withdraw my objection to your patch, if the patch (or similar) in the
> > thread I mentioned (http://sourceware.org/ml/gdb-patches/2006-05/msg00008.html)
> > is also approved.  So there appears to be some consensus here.
> 
> FWIW, I agree that the patch in
> http://sourceware.org/ml/gdb-patches/2006-05/msg00008.html
> is good, as it removes the need to do -var-evaluate-expression 
> or -var-update after setting variable's format.

This is great.
However, instead of Vladimir's patch, can we instead only use the natural format?
A patch similar to what I suggested in: http://sourceware.org/ml/gdb/2008-01/msg00072.html
Maybe renaming the print_value field to something more descriptive?

This should also fix the var-update problem when floats and strings only change
in the natural format (please refer to the sub-thread http://sourceware.org/ml/gdb/2008-01/msg00175.html)
In my mind, this will revert to what var-update was doing in GDB 6.5 (not sure about 6.6)
with the added benefit of fixing the string problem that Nick mentioned ("GNU" vs "GDB")

Thanks a lot!

Marc

RE: -var-update using formatted value

[Marc Khouzam]

> You can see what Emacs 22.1 does quite easily.  You probably don't want to look
> through thousands of lines of lisp code (gdb-ui.el) but you can just set
> gdb-enable-debug to t and look at the value of gdb-debug-log after issuing some
> commands to GDB in a session in Emacs (M-x gdb) so see the transactions.

I downloaded emacs 22.1 a gave it a spin.  It's pretty cool, the new GUI for GDB.
But I don't know how to set gdb-enable-debug to t or to look at gdb-debug-log after.
My emacs is pretty darn rusty.
I also couldn't figure out how to change the format to hex for a watch expression.

I did have a look at gdb-ui.el and I saw pretty much every -var-command used but 
I could not find any reference to -var-set-format...

> In fact, I'd be interested to know how well (badly?) GDB in Emacs performs
> in an embedded environment.

I currently don't have a setup to properly test this, but it is something we
will be eventually looking into.  At that time, I can give emacs a try.

Marc

RE: -var-update using formatted value

[Nick Roberts]

 > I downloaded emacs 22.1 a gave it a spin.  It's pretty cool, the new GUI for
 > GDB.  But I don't know how to set gdb-enable-debug to t or to look at
 > gdb-debug-log after.  My emacs is pretty darn rusty.  I also couldn't figure
 > out how to change the format to hex for a watch expression.
 > 
 > I did have a look at gdb-ui.el and I saw pretty much every -var-command used
 > but I could not find any reference to -var-set-format...

Sorry I wasn't clear.  Changing format is currently only possible in Emacs from
the CVS repository at Savannah (savannah.gnu.org/projects/emacs).  

It's changed by right clicking in the speedbar to get a pop up menu and
selecting the appropriate format from the "Output Format" sub-menu

I can send you a small patch to do that (which incidentally only updates
properly for 6.7, or later) but if we can get approval for Vladimir's patch (or
similar) I'll have to change what is in the repository, so it would be better
to wait till then.

 > > In fact, I'd be interested to know how well (badly?) GDB in Emacs performs
 > > in an embedded environment.
 > 
 > I currently don't have a setup to properly test this, but it is something we
 > will be eventually looking into.  At that time, I can give emacs a try.

Cool.  I've thought about what you said on dsdp-dd-dev about -var-list-children
and I think Emacs could be changed to just create/update those watch
expressions which are visible.  If you have questions about the mode it's
probably best to post to emacs-devel.  For general Emacs questions, like how to
set gdb-enable-debug to t or to look at gdb-debug-log, feel free to mail me off
list.


-- 
Nick http://www.inet.net.nz/~nickrob

RE: -var-update using formatted value

[Nick Roberts]

 > > FWIW, I agree that the patch in
 > > http://sourceware.org/ml/gdb-patches/2006-05/msg00008.html
 > > is good, as it removes the need to do -var-evaluate-expression 
 > > or -var-update after setting variable's format.
 > 
 > This is great.  However, instead of Vladimir's patch, can we instead only
 > use the natural format?  A patch similar to what I suggested in:
 > http://sourceware.org/ml/gdb/2008-01/msg00072.html Maybe renaming the
 > print_value field to something more descriptive?

Can you post a patch (to gdb-patches) so we can see exactly what you mean?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: RE: -var-update using formatted value

[Daniel Jacobowitz]

On Tue, Jan 15, 2008 at 11:32:16PM +0300, Vladimir Prus wrote:
> commit 67da794ce92c9af5fc9bc22721a942af27ade3d7
> Author: Vladimir Prus <vladimir@codesourcery.com>
> Date:   Tue Jan 15 23:29:36 2008 +0300
> 
>     Update stored value when format changes.
>     
>     	* varobj.c (varobj_set_display_format): Recomputed
>     	print_value.
>     	(c_value_of_variable): Return print_value.

This patch, with xstrdup instead of strdup, is OK.

-- 
Daniel Jacobowitz
CodeSourcery

Re: -var-update using formatted value

[Daniel Jacobowitz]

On Mon, Jan 14, 2008 at 07:33:49PM +1300, Nick Roberts wrote:
>  > I was suggesting:
>  > 
>  > (gdb) print 0b1101
>  > $1 = 13
> 
> I guess the change below to c-exp.y does that, at least for C.  But AFAIK 0b
> is not a recognised prefix for C.

> the change below to printcmd.c does this.  This seems to be consistent with
> existing usage, e.g. in Modula-2 hexadecimals are input like 0FFH but
> output in a lanuage independent way as 0xff.

Thanks.  This is exactly what I meant.  If you have time, could you
post this to gdb-patches along with news/manual/testsuite bits?  If
not, I'll do it (but no promises when I'll get to it).

-- 
Daniel Jacobowitz
CodeSourcery

Re: -var-update using formatted value

[Nick Roberts]

 > >  > I was suggesting:
 > >  > 
 > >  > (gdb) print 0b1101
 > >  > $1 = 13
 > > 
 > > I guess the change below to c-exp.y does that, at least for C.  But AFAIK
 > > 0b is not a recognised prefix for C.
 > 
 > > the change below to printcmd.c does this.  This seems to be consistent with
 > > existing usage, e.g. in Modula-2 hexadecimals are input like 0FFH but
 > > output in a lanuage independent way as 0xff.
 > 
 > Thanks.  This is exactly what I meant.  If you have time, could you
 > post this to gdb-patches along with news/manual/testsuite bits?  If
 > not, I'll do it (but no promises when I'll get to it).

Both changes, i.e., printcmd.c and c-exp.y?

Presumably if the change to c-exp.y is committed, there should be similar
changes to ada-exp.y, f-exp.y etc.  Does it not matter that this prefix
is not part of the underlying language?

Also, I think only the change to printcmd.c is necessary to solve Marcs bug
report about -var-update.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: -var-update using formatted value

[Daniel Jacobowitz]

On Wed, Jan 30, 2008 at 12:48:40PM +1300, Nick Roberts wrote:
> Both changes, i.e., printcmd.c and c-exp.y?

Right.

> Presumably if the change to c-exp.y is committed, there should be similar
> changes to ada-exp.y, f-exp.y etc.  Does it not matter that this prefix
> is not part of the underlying language?

Right.  As long as it doesn't conflict with the underlying language,
no, it doesn't matter - GDB tries to accept the whole source language,
but also accepts other things.

> Also, I think only the change to printcmd.c is necessary to solve Marcs bug
> report about -var-update.

I think that report is covered by two of the other patches I reviewed
today.

-- 
Daniel Jacobowitz
CodeSourcery

Re: -var-update using formatted value

[Nick Roberts]

Daniel Jacobowitz writes:
 > On Wed, Jan 30, 2008 at 12:48:40PM +1300, Nick Roberts wrote:
 > > Both changes, i.e., printcmd.c and c-exp.y?
 > 
 > Right.
 > 
 > > Presumably if the change to c-exp.y is committed, there should be similar
 > > changes to ada-exp.y, f-exp.y etc.  Does it not matter that this prefix
 > > is not part of the underlying language?
 > 
 > Right.  As long as it doesn't conflict with the underlying language,
 > no, it doesn't matter - GDB tries to accept the whole source language,
 > but also accepts other things.

I wouldn't know if it did conflict, but unless I hear otherwise I'll
assume it doesn't. In addition to c-exp.y, I'll amend:

ada-exp.y
f-exp.y
jv-exp.y
m2-exp.y
objc-exp.y
p-exp.y

and write some tests.  However, I can't run the testsuite for all these as I
don't have the compilers on my system.

The manual describes how integer constants should be typed for the various
languages under the Languages node but not how they are printed with the
various output formats under Examining.  I guess they should be changed in
both places.

Since the printcmd.c patch only has to be done in one place, I'll start with
that.

 > > Also, I think only the change to printcmd.c is necessary to solve Marcs bug
 > > report about -var-update.
 > 
 > I think that report is covered by two of the other patches I reviewed
 > today.

I don't think so.  The other patches cover the wrong format not detecting
a change in value, e.g. 1 -> 1.5 as decimal.

This change covers a change in format masking a change in value.  Marc's
example was 11 -> 3 = 11 (binary).

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: RE: -var-update using formatted value

[Nick Roberts]

Daniel Jacobowitz writes:
 > On Tue, Jan 15, 2008 at 11:32:16PM +0300, Vladimir Prus wrote:
 > > commit 67da794ce92c9af5fc9bc22721a942af27ade3d7
 > > Author: Vladimir Prus <vladimir@codesourcery.com>
 > > Date:   Tue Jan 15 23:29:36 2008 +0300
 > > 
 > >     Update stored value when format changes.
 > >     
 > >     	* varobj.c (varobj_set_display_format): Recomputed
 > >     	print_value.
 > >     	(c_value_of_variable): Return print_value.
 > 
 > This patch, with xstrdup instead of strdup, is OK.

Vladimir,

Can you please commit this change?

TIA

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: RE: -var-update using formatted value

[Vladimir Prus]

Nick Roberts wrote:

> Daniel Jacobowitz writes:
>  > On Tue, Jan 15, 2008 at 11:32:16PM +0300, Vladimir Prus wrote:
>  > > commit 67da794ce92c9af5fc9bc22721a942af27ade3d7
>  > > Author: Vladimir Prus <vladimir@codesourcery.com>
>  > > Date:   Tue Jan 15 23:29:36 2008 +0300
>  > > 
>  > >     Update stored value when format changes.
>  > >     
>  > >     * varobj.c (varobj_set_display_format): Recomputed
>  > >     print_value.
>  > >     (c_value_of_variable): Return print_value.
>  > 
>  > This patch, with xstrdup instead of strdup, is OK.
> 
> Vladimir,
> 
> Can you please commit this change?

Nick,
the change is now in.

Thanks,
Volodya