This is the mail archive of the gdb-patches@sourceware.org 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: Patch: implement new dynamic varobj spec


> Nick> 2) -var-update seems to list changes to children of dynamic
> Nick> objects in reverse numerical order.

> Oh, odd.  But not a bug, really, as the order is not specified.

It might not be a bug but it's desirable to list them in order as that makes
it easier to insert them into the existing list.  In fact it would also make
things easier if the "exp" field of -var-list-children was just a number and
this would make it consistent with ordinary arrays.  The patch below changes
output from

-var-list-children --all-values var2
^done,numchild="4",displayhint="map",children=[child={name="var2.[0]",exp="[0]",numchild="0",type="const std::basic_string<char, std::char_traits<char>, std::allocator<char> >",thread-id="1",dynamic="1"},child={name="var2.[1]",exp="[1]", ...

to

-var-list-children var2
^done,numchild="4",displayhint="map",children=[child={name="var2.0",exp="0",numchild="0",type="const std::basic_string<char, std::char_traits<char>, std::allocator<char> >",thread-id="1",dynamic="1"},child={name="var2.1",exp="1", ...

This also changes the name field of the varobj.

> The real intent for limiting the range is not to save memory but to
> avoid problems printing uninitialized containers.  I think a front end
> ought to always restrict the range when fetching the children of a
> dynamic varobj.  I suppose I will update the documentation to say this.

> For dynamic varobjs, we do save a bit of memory because the TO argument
> limits how many children we compute.

> Nick> Likewise with -var-set-update-range: does GDB track all changes
> Nick> and just report a restricted set, or restrict what it tracks?

> It always starts over at 0, and then filters on the low side after
> computing differences.  On the high side, TO (really TO+1, due to
> has_more computation) limits how many children we fetch.

You're right, response time rather than memory is the issue.  We can
probably create a large number of variable objects and just filter which
values we track.


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



>From the branch archer-tromey-python at git://sourceware.org/git/archer.git:


diff --git a/gdb/varobj.c b/gdb/varobj.c
index e884e19..6e6e58c 100644
--- a/gdb/varobj.c
+++ b/gdb/varobj.c
@@ -1028,15 +1028,21 @@ update_dynamic_varobj_children (struct varobj *var,
       if (to < 0 || i < to)
 	{
 	  PyObject *py_v;
+	  char *py_name;
 	  char *name;
+	  int len;
 	  struct value *v;
 	  struct cleanup *inner;
 
 	  inner = make_cleanup_py_decref (item);
 
-	  if (!PyArg_ParseTuple (item, "sO", &name, &py_v))
+	  if (!PyArg_ParseTuple (item, "sO", &py_name, &py_v))
 	    error (_("Invalid item from the child list"));
 
+	  /* Strip square brackets from string.  */
+	  len = strlen (py_name);
+	  name = strndup (py_name + 1, len - 2);
+
 	  v = convert_value_from_python (py_v);
 	  install_dynamic_child (var, changed, new, unchanged,
 				 cchanged, i, name, v);


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