This is the mail archive of the
mailing list for the GDB project.
Re: -var-update @
> > 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?
int myvar = 5;
int myvar1 = 5;
float myvar = 7.8;
int myvar1 = 7;
Stop Gdb on the return statement in mysub, then:
-var-create - @ myvar
-var-create - @ myvar1
~"#1 0x0804837f in main () at temp5.c:13\n"
~"13\t mysub ();\n"
-var-update --all-values var1
-var-update --all-values var2
> > 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.