This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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?

mysub ()
  int myvar = 5;
  int myvar1 = 5;

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]