-var-update @

[Nick Roberts]

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

I'm not sure that I would advocate it's removal just yet, but yes it does
seem to be best for the frontend to keep track of the state of the debugger
rather than Gdb 

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

void
mysub ()
{
  int myvar = 5;
  int myvar1 = 5;
  return;
}

main ()
{
  float myvar = 7.8;
  int myvar1 = 7;
  mysub ();
}

Stop Gdb on the return statement in mysub, then:

(gdb) 
-var-create - @ myvar
^done,name="var1",numchild="0",value="5",type="int",thread-id="1"
(gdb) 
-var-create - @ myvar1
^done,name="var2",numchild="0",value="5",type="int",thread-id="1"
(gdb) 
up
&"up\n"
~"#1  0x0804837f in main () at temp5.c:13\n"
~"13\t  mysub ();\n"
^done
(gdb) 
-var-update --all-values var1
^done,changelist=[{name="var1",in_scope="true",new_type="float",new_num_children="0"}]
(gdb) 
-var-update --all-values var2
^done,changelist=[{name="var2",value="-1080652880",in_scope="true",type_changed="false"}]
(gdb) 



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

There's a logic there if the frontend knows when the variable objects that are
bound to a frame will not change.  If there's a console, the user can change
the value with "p myvar=9", say, and the frontend wouldn't know directly that
such a variable object had changed value.

However, on reflection there is no harm in having this functionality as I see
now that "*" updates both kinds of objects so a frontend needn't use it.

I would just suggest a more consistent syntax as currently:

-var-update @     Updates all floating variable objects.
-var-update *     Updates all variable objects.
-var-update var1  Updates the variable object var1 (floating or otherwise).

-var-create - @   Creates a floating variable object.
-var-create - *   Creates a fixed frame variable object.

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