Re: -var-update @

[Vladimir Prus <vladimir at codesourcery dot com>]

On Thursday 27 March 2008 12:53:34 Nick Roberts wrote:
>  > > 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)

This is weird. I did not look at var1 missing new value (should be easy), but the
var2 behaviour is strange. Evaluating 'myvar1' by hand gives the right value,
whereas -var-update gives this apparent garbage. My guess is that that parsed
expression somehow holds on to frame. I'll look further.

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

IIUC, the above is that current syntax? If yes, how do you propose to
change. If this is the proposed syntax, can you spell out the difference
from the current one?

Incidentally, it seems to be that a really smart frontend might be updating only
those variable objects that a visible on screen. To support this case efficiently,
we'd better support

	-var-update var1 var2 var3 ...

syntax. I'm not proposing such a syntax right now -- we'd need to actually play
with such a smart frontend.

- Volodya