Re: -var-update @

[Nick Roberts <nickrob at snap dot net dot nz>]

Vladimir Prus writes:
 > 
 > I've checked it the attached patch which allows one to issue
 > 
 > 	-var-update @
 > 
 > and have all @-varobjs (or floating varobjs, as Nick suggested to name them),
 > updated. I believe this is the only reasonable way to make @ varobjs, which
 > are not bound to thread/frame/block to adequately work in MT program. 

This doesn't seem right to me but then there hasn't been any discussion.

According to the manual in "-var-create - * EXPRESSION", "*" means "current
frame" (it's actually the selected frame because if you go up a frame, you can
create a variable object there, but as I say the manual mixes the terms).

Whereas in "-var-update *", "*" means "all variable objects", as in a wildcard
character.

So I think it's wrong to equate the two uses of "*" which looks like what
you've done with "@".

 >                                                                  Otherwise,
 > if frontend switches thread or frame and wishes to update floating varobjs,
 > it should either to "-var-update *", which is extra work, or update varobjs
 > one-by-one, which is also not very nice.

I think that's exactly how it's mean't to work, although it's currently broken.
The usual use case that's cited is recursive functions.

Using "-var-create - @ EXPRESSION" if there are two frames and you have "int
myvar" in one and "float myvar" in the other, when you change frame, you get
something like:

-var-update --all-values *
^done,changelist=[{name="var1",in_scope="true",new_type="float",new_num_children="0"},

which is missing the value field.

with ints in both frames, moving up from the frame the variable object was
created in I get something like:

-var-update --all-values *
^done,changelist=[{name="var2",value="7",in_scope="true",type_changed="false"}]
(gdb) 
up
&"up\n"
~"#1  0x08048a00 in main (argc=-72539512, argv=0xbfca8f74) at myprog.c:232\n"
~"232\t    asdf = myprint (2*i, *(a + i) /* hello */);\n"
^done
(gdb)
-var-update --all-values *
^done,changelist=[{name="var2",value="-1077244176",in_scope="true",type_changed="false"}]

when the value is really 0 in the upper frame.


I think we should fix (and document) such floating variable objects but I
really don't think we want a second command to update them.

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