Re: -var-update @

[Vladimir Prus <ghost@cs.msu.su>]

Nick Roberts wrote:

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

So, you think the change might create confusion for *users* for MI interface.
Clearly, as far as behaviour goes, no equation of two uses of "*" was done.
I think it might be unfortunate that '*' means different things in different
context, but that's what we have now, and probably the first fix to to 
remove '-var-create *' from the manual and educate frontend authors to use
the frame explicitly, as that will make the protocol even less stateful.
 
>  >                                                                  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.

Sorry, I don't quite get, from your description, when the output of -var-update
misses the value, and when the value is wrong -- it sounds like both cases happen
when you do -var-update in a different frame. Can you clarify, or maybe create a testcase
for this?

> I think we should fix (and document) such floating variable objects 

We should; I was not aware of the bug with wrong value you report above.

> but I really don't think we want a second command to update them.

Let me try again. You are using '-var-update *' above. This command will update all
variable objects, including those that a bound to a frame.  There's no need to update
variable objects that are bound to a frame -- a change to selected thread or frame
will not change them at all. Updating variable object can take considerable time,
and therefore it's better to be able to update only floating variable object.

Is any bit of the logic above faulty?

- Volodya