-var-update @

-var-update @

[Vladimir Prus]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]


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

- Volodya

2008-03-26  Vladimir Prus  <vladimir@codesourcery.com>

	* varobj.h (varobj_floating_p): Declare.
	* varobj.c (varobj_floating_p): New.
	* mi/mi-cmd-var.c (mi_cmd_var_update): When passed
	'@' as the name, update all floating varobjs.


[-- Attachment #2: commit.diff --]
[-- Type: text/x-diff, Size: 2232 bytes --]

Index: varobj.c
===================================================================
RCS file: /cvs/src/src/gdb/varobj.c,v
retrieving revision 1.107
diff -u -p -r1.107 varobj.c
--- varobj.c	26 Mar 2008 14:11:18 -0000	1.107
+++ varobj.c	26 Mar 2008 14:48:37 -0000
@@ -1868,6 +1868,15 @@ varobj_value_is_changeable_p (struct var
   return r;
 }
 
+/* Return 1 if that varobj is floating, that is is always evaluated in the
+   selected frame, and not bound to thread/frame.  Such variable objects
+   are created using '@' as frame specifier to -var-create.  */
+int
+varobj_floating_p (struct varobj *var)
+{
+  return var->root->floating;
+}
+
 /* Given the value and the type of a variable object,
    adjust the value and type to those necessary
    for getting children of the variable object.
Index: varobj.h
===================================================================
RCS file: /cvs/src/src/gdb/varobj.h,v
retrieving revision 1.16
diff -u -p -r1.16 varobj.h
--- varobj.h	24 Mar 2008 17:33:30 -0000	1.16
+++ varobj.h	26 Mar 2008 14:48:37 -0000
@@ -124,4 +124,6 @@ extern void varobj_invalidate (void);
 
 extern int varobj_editable_p (struct varobj *var);
 
+extern int varobj_floating_p (struct varobj *var);
+
 #endif /* VAROBJ_H */
Index: mi/mi-cmd-var.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmd-var.c,v
retrieving revision 1.46
diff -u -p -r1.46 mi-cmd-var.c
--- mi/mi-cmd-var.c	24 Mar 2008 17:33:30 -0000	1.46
+++ mi/mi-cmd-var.c	26 Mar 2008 14:48:39 -0000
@@ -558,7 +558,7 @@ mi_cmd_var_update (char *command, char *
   /* Check if the parameter is a "*" which means that we want
      to update all variables */
 
-  if ((*name == '*') && (*(name + 1) == '\0'))
+  if ((*name == '*' || *name == '@') && (*(name + 1) == '\0'))
     {
       nv = varobj_list (&rootlist);
       cleanup = make_cleanup (xfree, rootlist);
@@ -574,7 +574,8 @@ mi_cmd_var_update (char *command, char *
       cr = rootlist;
       while (*cr != NULL)
 	{
-	  varobj_update_one (*cr, print_values, 0 /* implicit */);
+	  if (*name == '*' || varobj_floating_p (*cr))
+	    varobj_update_one (*cr, print_values, 0 /* implicit */);
 	  cr++;
 	}
       do_cleanups (cleanup);

Re: -var-update @

[Nick Roberts]

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

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


I think we should fix (and document) such floating variable objects but I
really don't think we want a second command to update them.

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

Re: -var-update @

[Vladimir Prus]

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

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

Re: -var-update @

[Vladimir Prus]

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

RE: -var-update @

[Marc Khouzam]

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

DSF only updates varObj that are visible on screen.
So currently, it always uses -var-update with a single varObj name (never use *).

If I understand correctly,
> 	-var-update var1 var2 var3 ...
would allow the frontend to update multiple variable objects with a single command.
With the goal of reducing the number of MI commands.  Any other benefits?

In the case of DSF, we wouldn't be able to use such a command though.
The reason is that the views which show the variables are de-coupled from the
variable object manager; and those views request the value of each variable
individually, so the variable manager, which sends -var-update only gets
a single varObj request at a time.

Not to say that
> 	-var-update var1 var2 var3 ...
would not be useful to other "really smart frontends" :-)

And, who knows, it may not be too hard for the DSF views to send batch requests
containing all the visible variable objects, someday.

Marc

Re: -var-update @

[Vladimir Prus]

On Thursday 27 March 2008 16:24:40 Marc Khouzam wrote:
> 
> > 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.
> 
> DSF only updates varObj that are visible on screen.
> So currently, it always uses -var-update with a single varObj name (never use *).
> 
> If I understand correctly,
> > 	-var-update var1 var2 var3 ...
> would allow the frontend to update multiple variable objects with a single command.
> With the goal of reducing the number of MI commands.  Any other benefits?

Someday, GDB might be able to batch requests to the targets. So, instead of N
roundtrips over slow JTAG connection, you can have single one.

> In the case of DSF, we wouldn't be able to use such a command though.
> The reason is that the views which show the variables are de-coupled from the
> variable object manager; and those views request the value of each variable
> individually, so the variable manager, which sends -var-update only gets
> a single varObj request at a time.

Heh, that's what you get for using nice component design :-)
Of course, batching requests in GDB might prove even more complicated.

> Not to say that
> > 	-var-update var1 var2 var3 ...
> would not be useful to other "really smart frontends" :-)
> 
> And, who knows, it may not be too hard for the DSF views to send batch requests
> containing all the visible variable objects, someday.

Yes.

- Volodya

RE: -var-update @

[Nick Roberts]

 > DSF only updates varObj that are visible on screen.  So currently, it always
 > uses -var-update with a single varObj name (never use *).

Which must mean that there is a round trip to the target for each variable
object that needs to be updated.

This is sounds similar to the previous discussion about using
"-var-list-children --all-values".  There Daniel stated that "for a lot of
embedded targets [...] reading memory becomes the dominant time delay".

Can someone give some typical numbers for "round trip time" vs "reading memory"
time.  In my naive understanding of embedded targets, I would have thought the
"round trip time" might be large due to a slow serial link, while "reading
memory" wouldn't change much as all RAM is pretty much the same.  Or is the
latter slow because of the time taken to transfer any unneeded extra data back
to the host?

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

RE: -var-update @

[Marc Khouzam]

> > DSF only updates varObj that are visible on screen.  So currently, it always
> > uses -var-update with a single varObj name (never use *).
> 
> Which must mean that there is a round trip to the target for each variable
> object that needs to be updated.
> 
> This is sounds similar to the previous discussion about using
> "-var-list-children --all-values".  There Daniel stated that "for a lot of
> embedded targets [...] reading memory becomes the dominant time delay".
> 
> Can someone give some typical numbers for "round trip time" vs "reading memory"
> time.  In my naive understanding of embedded targets, I would have thought the
> "round trip time" might be large due to a slow serial link, while "reading
> memory" wouldn't change much as all RAM is pretty much the same.  Or is the
> latter slow because of the time taken to transfer any unneeded extra data back
> to the host?

I'm not familiar with such numbers myself, although I would be interested in
finding out.

However, I wanted to point out that there are currently two possible options
for var-update

-var-update <singleVarObj>
-var-update *
(we'll ignore the new -var-update @, which does not affect the discussion)

For DSF, which tries to minimize the amount of work done, we can:

1- use multiple var-update <singleVarObj>, which typically results in 
about 5 or 6 var-updates being sent (only 5 or 6 variables are visible on-screen).
Then GDB on the target reads the memory for those 5 or 6 varObjs.

2- use var-update *, which results in a single -var-update, but which
makes GDB on the target read the memory of all varObjects, which can be
anywhere from, say, 5 to 5000, or even more.

As you can see, option 2 does not scale, irrespective of which is 
the true bottleneck, the round-trip time, or the target memory access.
That is why DSF does not use var-update *.

But you are right that less round-trips would be even better.
So, to improve option 1, Vladimir's suggestion of a batch -var-update
  -var-update <var1> <var2> ...
would be better (although DSF is not currently setup for it.)

BTW, is there a limit (enforced or recommended) on the number of varObj that
can be created?

BR,
Marc

Re: -var-update @

[Vladimir Prus]

On Friday 28 March 2008 17:31:33 Marc Khouzam wrote:
> 
> > > DSF only updates varObj that are visible on screen.  So currently, it always
> > > uses -var-update with a single varObj name (never use *).
> > 
> > Which must mean that there is a round trip to the target for each variable
> > object that needs to be updated.
> > 
> > This is sounds similar to the previous discussion about using
> > "-var-list-children --all-values".  There Daniel stated that "for a lot of
> > embedded targets [...] reading memory becomes the dominant time delay".
> > 
> > Can someone give some typical numbers for "round trip time" vs "reading memory"
> > time.  In my naive understanding of embedded targets, I would have thought the
> > "round trip time" might be large due to a slow serial link, while "reading
> > memory" wouldn't change much as all RAM is pretty much the same.  Or is the
> > latter slow because of the time taken to transfer any unneeded extra data back
> > to the host?
> 
> I'm not familiar with such numbers myself, although I would be interested in
> finding out.
> 
> However, I wanted to point out that there are currently two possible options
> for var-update
> 
> -var-update <singleVarObj>
> -var-update *
> (we'll ignore the new -var-update @, which does not affect the discussion)
> 
> For DSF, which tries to minimize the amount of work done, we can:
> 
> 1- use multiple var-update <singleVarObj>, which typically results in 
> about 5 or 6 var-updates being sent (only 5 or 6 variables are visible on-screen).
> Then GDB on the target reads the memory for those 5 or 6 varObjs.
> 
> 2- use var-update *, which results in a single -var-update, but which
> makes GDB on the target read the memory of all varObjects, which can be
> anywhere from, say, 5 to 5000, or even more.
> 
> As you can see, option 2 does not scale, irrespective of which is 
> the true bottleneck, the round-trip time, or the target memory access.

You can freeze variable objects that are not visible to the user,
and -var-update * won't fetch those. Please see the -var-set-frozen
command.

> That is why DSF does not use var-update *.
> 
> But you are right that less round-trips would be even better.
> So, to improve option 1, Vladimir's suggestion of a batch -var-update
>   -var-update <var1> <var2> ...
> would be better (although DSF is not currently setup for it.)
> 
> BTW, is there a limit (enforced or recommended) on the number of varObj that
> can be created?

There's no hard limit. The practical limit depends on target and can only
be found empirically.

- Volodya

RE: -var-update @

[Marc Khouzam]

> > For DSF, which tries to minimize the amount of work done, we can:
> > 
> > 1- use multiple var-update <singleVarObj>, which typically results in 
> > about 5 or 6 var-updates being sent (only 5 or 6 variables are 
> > visible on-screen). Then GDB on the target reads the memory for 
> > those 5 or 6 varObjs.
> > 
> > 2- use var-update *, which results in a single -var-update, but which
> > makes GDB on the target read the memory of all varObjects, which can be
> > anywhere from, say, 5 to 5000, or even more.
> > 
> > As you can see, option 2 does not scale, irrespective of which is 
> > the true bottleneck, the round-trip time, or the target memory access.
> 
> You can freeze variable objects that are not visible to the user,
> and -var-update * won't fetch those. Please see the -var-set-frozen
> command.

I handn't thought of that.  Although, this also comes with its own drawbacks.
If the user scrolls the variable view, new varObjects will need to be updated,
but they will need to be unfrozen first, and the newly hidden ones will
need to be frozen.  In the end, I think it will end up being more commands
than using var-update <varObj>.

With DSF updating only visible varObjs, I think var-update <varObj> is 
sufficiently efficient.

Marc

Re: -var-update @

[André Pönitz]

On Thursday 27 March 2008 21:58:09 Nick Roberts wrote:
>  > DSF only updates varObj that are visible on screen.  So currently, it always
>  > uses -var-update with a single varObj name (never use *).
> 
> Which must mean that there is a round trip to the target for each variable
> object that needs to be updated.

One usually can issue all commands at once without waiting for the results
to show up first. So depending on circumstances asking $n questions might 
take considerably less time than $n "full roundtrips".

Having said that, roundtrip times are indeed reducing the utility of
the current mi interface: One needs simply too much 'real' roundtrips to
get a screenfull of information. 

As an example I don't need the 'intermediate level' of public/protected/private
information for C++ objects, since I do not want to display that anyway.
Yet I have to ask for --all-children, wait for the response, parse it, only to
discover that it cointains a, say, private and a public block, and ask again
for the 'real' children now. So that's two full roundtrips for what could be one...

Regards,
Andre'

RE: -var-update @

[Marc Khouzam]

> As an example I don't need the 'intermediate level' of public/protected/private
> information for C++ objects, since I do not want to display that anyway.
> Yet I have to ask for --all-children, wait for the response, parse it, only to
> discover that it cointains a, say, private and a public block, and ask again
> for the 'real' children now. So that's two full roundtrips for what could be one...

That is good example of something that would be nice to improve.
Maybe having a -depth option to the var-list-children command?
In DSF, we always go to a full depth, so we have no real use for having to
separately query at each level of children.

Marc

Re: -var-update @

[André Pönitz]

On Tuesday 01 April 2008 15:23:29 Marc Khouzam wrote:
> 
> > As an example I don't need the 'intermediate level' of public/protected/private
> > information for C++ objects, since I do not want to display that anyway.
> > Yet I have to ask for --all-children, wait for the response, parse it, only to
> > discover that it cointains a, say, private and a public block, and ask again
> > for the 'real' children now. So that's two full roundtrips for what could be one...
> 
> That is good example of something that would be nice to improve.
> Maybe having a -depth option to the var-list-children command?

I am rarely interested in seeing deeper levels 'immediately', 
and if so, it's unlikely that I'd need the same level for all 
children. Just having an option to skip the 'access' level
would be nice. The access information could even be listed
in the child items directly, so there would be no loss of 
information for the frontend at all...

> In DSF, we always go to a full depth, so we have no real use for having to
> separately query at each level of children.

Honestly, the biggest improvement for me would be 'stateless MI', 
i.e. basically '-evaluate-expression' and '-list-children' without 
varobjects being created at all.

I live in a almost pure C++ enviroment, so I display a, say,
 std::map<int, std::string>  as a two-column table, not as 
'a bunch of structures containing pointers to each other'
(no offense to std::map<> implementors implied ;-) ).

Stateful varobject do not really help e.g. for getting
a notification when a new key/value pair gets inserted, as
this can basically happen everywhere in the tree.

Of course, I do not expect gdb to do my job in interpreting
the raw structures, but as it stands, some of the available
operations are "too high level" for me as they try to help me
in a way (like automatically creating varobjects, or, say
returning "cooked" data for char* values) that I have a hard
time to "actively ignore" ;-)

Regards,
Andre'

Re: -var-update @

[Daniel Jacobowitz]

On Tue, Apr 01, 2008 at 04:13:34PM +0200, André Pönitz wrote:
> Of course, I do not expect gdb to do my job in interpreting
> the raw structures,

In any case, I expect the next version of GDB will support it :-)
Hopefully that will make varobjs more of a help, and less of a
hindrance.

-- 
Daniel Jacobowitz
CodeSourcery

Re: -var-update @

[Daniel Jacobowitz]

On Fri, Mar 28, 2008 at 08:58:09AM +1200, Nick Roberts wrote:
>  > DSF only updates varObj that are visible on screen.  So currently, it always
>  > uses -var-update with a single varObj name (never use *).
> 
> Which must mean that there is a round trip to the target for each variable
> object that needs to be updated.
> 
> This is sounds similar to the previous discussion about using
> "-var-list-children --all-values".  There Daniel stated that "for a lot of
> embedded targets [...] reading memory becomes the dominant time delay".
> 
> Can someone give some typical numbers for "round trip time" vs "reading memory"
> time.  In my naive understanding of embedded targets, I would have thought the
> "round trip time" might be large due to a slow serial link, while "reading
> memory" wouldn't change much as all RAM is pretty much the same.  Or is the
> latter slow because of the time taken to transfer any unneeded extra data back
> to the host?

Reading memory from the target is usually, in my experience, dominated
by round trip time.  There's at least three different round trips
involved: MI frontend to GDB, GDB to debug server, debug server over
hardware probe to the target.  Because GDB and the remote protocol
are synchronous, only one memory read can happen at a time, so the
first two always have to wait at least the length of the last one.
A typical USB probe takes between 3ms and 10ms to read memory; that's
just how USB works.  I've seen reports that on Windows's USB stack
it's more like 50ms but I haven't confirmed that myself yet.

For typical use this delay is independent of the amount of memory
you're reading, until it gets very large.  Four bytes and four hundred
take about the same time.

-- 
Daniel Jacobowitz
CodeSourcery

Re: -var-update @

[Michael Snyder]

On Thu, 2008-04-03 at 14:58 -0400, Daniel Jacobowitz wrote:
> On Fri, Mar 28, 2008 at 08:58:09AM +1200, Nick Roberts wrote:
> >  > DSF only updates varObj that are visible on screen.  So currently, it always
> >  > uses -var-update with a single varObj name (never use *).
> > 
> > Which must mean that there is a round trip to the target for each variable
> > object that needs to be updated.
> > 
> > This is sounds similar to the previous discussion about using
> > "-var-list-children --all-values".  There Daniel stated that "for a lot of
> > embedded targets [...] reading memory becomes the dominant time delay".
> > 
> > Can someone give some typical numbers for "round trip time" vs "reading memory"
> > time.  In my naive understanding of embedded targets, I would have thought the
> > "round trip time" might be large due to a slow serial link, while "reading
> > memory" wouldn't change much as all RAM is pretty much the same.  Or is the
> > latter slow because of the time taken to transfer any unneeded extra data back
> > to the host?
> 
> Reading memory from the target is usually, in my experience, dominated
> by round trip time.  There's at least three different round trips
> involved: MI frontend to GDB, GDB to debug server, debug server over
> hardware probe to the target.  Because GDB and the remote protocol
> are synchronous, only one memory read can happen at a time, so the
> first two always have to wait at least the length of the last one.
> A typical USB probe takes between 3ms and 10ms to read memory; that's
> just how USB works.  I've seen reports that on Windows's USB stack
> it's more like 50ms but I haven't confirmed that myself yet.
> 
> For typical use this delay is independent of the amount of memory
> you're reading, until it gets very large.  Four bytes and four hundred
> take about the same time.

Only if gdb requests it all in one go.
Sometimes it reads it a word at a time...
in that case all those round trips can really add up!

Re: -var-update @

[Nick Roberts]

 > > -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 the patch below fixes the behaviour for var2.  There may be a less
expensive way to do this, e.g, just update the "struct value", but I don't know
how to do that.

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

There's still no doc or tests for this type of varobj.

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

This is the current syntax which I find confusing because "*" means "fixed" in
one context and "all" in another.  I'm not sure how to change it and remain
backward compatible.

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


2008-03-29  Nick Roberts  <nickrob@snap.net.nz>

	* varobj.c (varobj_update): Always mark floating variable objects
	as changed.
	(value_of_root): Always recreate a floating variable object.


*** varobj.c.~1.108.~	2008-03-27 08:02:16.000000000 +1200
--- varobj.c	2008-03-29 17:06:35.000000000 +1200
*************** varobj_update (struct varobj **varp, str
*** 1160,1177 ****
  	 has changed.  */
        new = value_of_root (varp, &type_changed);
        
!       /* If this is a floating varobj, and its type has changed,
! 	 them note that it's changed.  */
!       if (type_changed)
  	VEC_safe_push (varobj_p, result, *varp);
        
!         if (install_new_value ((*varp), new, type_changed))
! 	  {
! 	    /* If type_changed is 1, install_new_value will never return
! 	       non-zero, so we'll never report the same variable twice.  */
! 	    gdb_assert (!type_changed);
! 	    VEC_safe_push (varobj_p, result, *varp);
! 	  }
  
        if (new == NULL)
  	{
--- 1160,1176 ----
  	 has changed.  */
        new = value_of_root (varp, &type_changed);
        
!       /* If this is a floating varobj, then note that it's changed.  */
!       if ((*varp)->root->floating)
  	VEC_safe_push (varobj_p, result, *varp);
        
!       if (install_new_value ((*varp), new, type_changed))
! 	{
! 	  /* If type_changed is 1, install_new_value will never return
! 	     non-zero, so we'll never report the same variable twice.  */
! 	  gdb_assert (!type_changed);
! 	  VEC_safe_push (varobj_p, result, *varp);
! 	}
  
        if (new == NULL)
  	{
*************** value_of_root (struct varobj **var_handl
*** 1738,1758 ****
        old_type = varobj_get_type (var);
        new_type = varobj_get_type (tmp_var);
        if (strcmp (old_type, new_type) == 0)
- 	{
- 	  varobj_delete (tmp_var, NULL, 0);
  	  *type_changed = 0;
- 	}
        else
- 	{
- 	  tmp_var->obj_name =
- 	    savestring (var->obj_name, strlen (var->obj_name));
- 	  varobj_delete (var, NULL, 0);
- 
- 	  install_variable (tmp_var);
- 	  *var_handle = tmp_var;
- 	  var = *var_handle;
  	  *type_changed = 1;
! 	}
        xfree (old_type);
        xfree (new_type);
      }
--- 1737,1753 ----
        old_type = varobj_get_type (var);
        new_type = varobj_get_type (tmp_var);
        if (strcmp (old_type, new_type) == 0)
  	  *type_changed = 0;
        else
  	  *type_changed = 1;
! 
!       tmp_var->obj_name =
! 	savestring (var->obj_name, strlen (var->obj_name));
!       varobj_delete (var, NULL, 0);
!       install_variable (tmp_var);
!       *var_handle = tmp_var;
!       var = *var_handle;
! 
        xfree (old_type);
        xfree (new_type);
      }

Re: -var-update @

[Vladimir Prus]

On Saturday 29 March 2008 08:15:39 Nick Roberts wrote:
> *** varobj.c.~1.108.~   2008-03-27 08:02:16.000000000 +1200
> --- varobj.c    2008-03-29 17:06:35.000000000 +1200
> *************** varobj_update (struct varobj **varp, str
> *** 1160,1177 ****
>          has changed.  */
>         new = value_of_root (varp, &type_changed);
>         
> !       /* If this is a floating varobj, and its type has changed,
> !        them note that it's changed.  */
> !       if (type_changed)
>         VEC_safe_push (varobj_p, result, *varp);
>         
> !         if (install_new_value ((*varp), new, type_changed))
> !         {
> !           /* If type_changed is 1, install_new_value will never return
> !              non-zero, so we'll never report the same variable twice.  */
> !           gdb_assert (!type_changed);
> !           VEC_safe_push (varobj_p, result, *varp);
> !         }
>   
>         if (new == NULL)
>         {
> --- 1160,1176 ----
>          has changed.  */
>         new = value_of_root (varp, &type_changed);
>         
> !       /* If this is a floating varobj, then note that it's changed.  */
> !       if ((*varp)->root->floating)
>         VEC_safe_push (varobj_p, result, *varp);

What is the logic here? Surely, a floating varobj might as well not change.
         
> !       if (install_new_value ((*varp), new, type_changed))
> !       {
> !         /* If type_changed is 1, install_new_value will never return
> !            non-zero, so we'll never report the same variable twice.  */
> !         gdb_assert (!type_changed);
> !         VEC_safe_push (varobj_p, result, *varp);
> !       }
>   
>         if (new == NULL)
>         {
> *************** value_of_root (struct varobj **var_handl
> *** 1738,1758 ****
>         old_type = varobj_get_type (var);
>         new_type = varobj_get_type (tmp_var);
>         if (strcmp (old_type, new_type) == 0)
> -       {
> -         varobj_delete (tmp_var, NULL, 0);
>           *type_changed = 0;
> -       }
>         else
> -       {
> -         tmp_var->obj_name =
> -           savestring (var->obj_name, strlen (var->obj_name));
> -         varobj_delete (var, NULL, 0);
> - 
> -         install_variable (tmp_var);
> -         *var_handle = tmp_var;
> -         var = *var_handle;
>           *type_changed = 1;
> !       }
>         xfree (old_type);
>         xfree (new_type);
>       }
> --- 1737,1753 ----
>         old_type = varobj_get_type (var);
>         new_type = varobj_get_type (tmp_var);
>         if (strcmp (old_type, new_type) == 0)
>           *type_changed = 0;
>         else
>           *type_changed = 1;
> ! 
> !       tmp_var->obj_name =
> !       savestring (var->obj_name, strlen (var->obj_name));
> !       varobj_delete (var, NULL, 0);
> !       install_variable (tmp_var);
> !       *var_handle = tmp_var;
> !       var = *var_handle;
> ! 
>         xfree (old_type);
>         xfree (new_type);
>       }

Hmm, I see. This actually causes a new varobj to be created each time.

> I think the patch below fixes the behaviour for var2.  There may be a
> less expensive way to do this, e.g, just update the "struct value",
> but I don't know how to do that.

So, we still don't know why the current code does not work? I think
we still get to figure out, to make sure that whatever bug there is
does not affect other cases.

- Volodya

Re: -var-update @

[Nick Roberts]

 > So, we still don't know why the current code does not work? I think
 > we still get to figure out, to make sure that whatever bug there is
 > does not affect other cases.

My patch didn't do the right thing (it always marked a floating variable
object as changed) but it's along the right lines.  How about this one?

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


2008-03-30  Nick Roberts  <nickrob@snap.net.nz>

	* varobj.c (value_of_root): Update expression of root for
	floating variable objects.



*** varobj.c.~1.108.~	2008-03-27 08:02:16.000000000 +1200
--- varobj.c	2008-03-30 15:41:44.000000000 +1200
*************** varobj_update (struct varobj **varp, str
*** 1739,1744 ****
--- 1739,1751 ----
        new_type = varobj_get_type (tmp_var);
        if (strcmp (old_type, new_type) == 0)
  	{
+ 	  struct expression *tmp_exp;
+ 
+ 	  /* Update expression to new frame.  */
+ 	  tmp_exp = var->root->exp;
+ 	  var->root->exp = tmp_var->root->exp;
+ 	  tmp_var->root->exp = tmp_exp;
+ 
  	  varobj_delete (tmp_var, NULL, 0);
  	  *type_changed = 0;
  	}

Re: -var-update @

[Vladimir Prus]

On Sunday 30 March 2008 07:54:08 Nick Roberts wrote:
>  > So, we still don't know why the current code does not work? I think
>  > we still get to figure out, to make sure that whatever bug there is
>  > does not affect other cases.
> 
> My patch didn't do the right thing (it always marked a floating variable
> object as changed) but it's along the right lines.  How about this one?

This patch seem to go in the right direction. I'm somewhat surprised that
evaluating previous expression gets bogus value, as opposed to getting
value in the frame where varobj was originally created. Any ideas why is that?

Do you think you can write some test to go along this patch?

Thanks,
Volodya

Re: -var-update @

[Nick Roberts]

Vladimir Prus writes:
 > On Sunday 30 March 2008 07:54:08 Nick Roberts wrote:
 > >  > So, we still don't know why the current code does not work? I think
 > >  > we still get to figure out, to make sure that whatever bug there is
 > >  > does not affect other cases.
 > > 
 > > My patch didn't do the right thing (it always marked a floating variable
 > > object as changed) but it's along the right lines.  How about this one?
 > 
 > This patch seem to go in the right direction. I'm somewhat surprised that
 > evaluating previous expression gets bogus value, as opposed to getting value
 > in the frame where varobj was originally created. Any ideas why is that?

I've not tried to understand _exactly_ what value was being retrieved, but
basically var->root->exp was obtained once from gdb_parse_exp_1 in
varobj_create and this has symbol information in var->root->exp->elts[2].
Previously this would be the symbol information for the variable in the frame
for which the variable object was created.  At the same time var->value was
being updated relative to the selected frame, which gave an incorrect address
value in value->address.  I guess a variable's numeric value on the stack is
computed using both the frame address and an address in the symbol table and
these were inconsistent.

	  /* Update expression to new frame.  */
	  tmp_exp = var->root->exp;
	  var->root->exp = tmp_var->root->exp;
	  tmp_var->root->exp = tmp_exp;

Moving var->root->exp into tmp_var->root->exp just ensures that this memory
gets freed when tmp_var is deleted:

	  varobj_delete (tmp_var, NULL, 0);

 > Do you think you can write some test to go along this patch?

We need some tests and documentation at some stage before the next release
but perhaps Bogdan can confirm that this patch works for him first.

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

Re: -var-update @

[Vladimir Prus]

On Friday 04 April 2008 00:04:03 Nick Roberts wrote:
> Vladimir Prus writes:
>  > On Sunday 30 March 2008 07:54:08 Nick Roberts wrote:
>  > >  > So, we still don't know why the current code does not work? I think
>  > >  > we still get to figure out, to make sure that whatever bug there is
>  > >  > does not affect other cases.
>  > > 
>  > > My patch didn't do the right thing (it always marked a floating variable
>  > > object as changed) but it's along the right lines.  How about this one?
>  > 
>  > This patch seem to go in the right direction. I'm somewhat surprised that
>  > evaluating previous expression gets bogus value, as opposed to getting value
>  > in the frame where varobj was originally created. Any ideas why is that?
> 
> I've not tried to understand _exactly_ what value was being retrieved, but
> basically var->root->exp was obtained once from gdb_parse_exp_1 in
> varobj_create and this has symbol information in var->root->exp->elts[2].
> Previously this would be the symbol information for the variable in the frame
> for which the variable object was created.  At the same time var->value was
> being updated relative to the selected frame, which gave an incorrect address
> value in value->address.  I guess a variable's numeric value on the stack is
> computed using both the frame address and an address in the symbol table and
> these were inconsistent.
> 
> 	  /* Update expression to new frame.  */
> 	  tmp_exp = var->root->exp;
> 	  var->root->exp = tmp_var->root->exp;
> 	  tmp_var->root->exp = tmp_exp;
> 
> Moving var->root->exp into tmp_var->root->exp just ensures that this memory
> gets freed when tmp_var is deleted:
> 
> 	  varobj_delete (tmp_var, NULL, 0);
> 
>  > Do you think you can write some test to go along this patch?
> 
> We need some tests and documentation at some stage before the next release
> but perhaps Bogdan can confirm that this patch works for him first.

Well, if your patch fixes the issue that *you* saw, then it's already an improvement,
and we better get it into the tree as soon as possible.

- Volodya

Re: -var-update @

[Vladimir Prus]

Vladimir Prus wrote:

> On Friday 04 April 2008 00:04:03 Nick Roberts wrote:
>> Vladimir Prus writes:
>>  > On Sunday 30 March 2008 07:54:08 Nick Roberts wrote:
>>  > >  > So, we still don't know why the current code does not work? I think
>>  > >  > we still get to figure out, to make sure that whatever bug there is
>>  > >  > does not affect other cases.
>>  > > 
>>  > > My patch didn't do the right thing (it always marked a floating variable
>>  > > object as changed) but it's along the right lines.  How about this one?
>>  > 
>>  > This patch seem to go in the right direction. I'm somewhat surprised that
>>  > evaluating previous expression gets bogus value, as opposed to getting value
>>  > in the frame where varobj was originally created. Any ideas why is that?
>> 
>> I've not tried to understand _exactly_ what value was being retrieved, but
>> basically var->root->exp was obtained once from gdb_parse_exp_1 in
>> varobj_create and this has symbol information in var->root->exp->elts[2].
>> Previously this would be the symbol information for the variable in the frame
>> for which the variable object was created.  At the same time var->value was
>> being updated relative to the selected frame, which gave an incorrect address
>> value in value->address.  I guess a variable's numeric value on the stack is
>> computed using both the frame address and an address in the symbol table and
>> these were inconsistent.
>> 
>> /* Update expression to new frame.  */
>> tmp_exp = var->root->exp;
>> var->root->exp = tmp_var->root->exp;
>> tmp_var->root->exp = tmp_exp;
>> 
>> Moving var->root->exp into tmp_var->root->exp just ensures that this memory
>> gets freed when tmp_var is deleted:
>> 
>> varobj_delete (tmp_var, NULL, 0);
>> 
>>  > Do you think you can write some test to go along this patch?
>> 
>> We need some tests and documentation at some stage before the next release
>> but perhaps Bogdan can confirm that this patch works for him first.
> 
> Well, if your patch fixes the issue that *you* saw, then it's already an improvement,
> and we better get it into the tree as soon as possible.

Nick,
for avoidance of doubt -- are you planning to finish this patch in near future?
If not, I'll pick it up.

- Volodya

Re: -var-update @

[Nick Roberts]

 > >>  > Do you think you can write some test to go along this patch?
 > >> 
 > >> We need some tests and documentation at some stage before the next release
 > >> but perhaps Bogdan can confirm that this patch works for him first.
 > > 
 > > Well, if your patch fixes the issue that *you* saw, then it's already an
 > > improvement, and we better get it into the tree as soon as possible.
 > 
 > Nick, for avoidance of doubt -- are you planning to finish this patch in
 > near future?  If not, I'll pick it up.

I think the patch is OK, so I don't know what to change there, but perhaps you
mean write some tests.  I must admit my enthusiasm has waned a bit and I've
not started this yet.  In either case, please feel free to finish it as you
see appropriate.

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