From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25878 invoked by alias); 13 Sep 2009 02:41:28 -0000 Received: (qmail 25832 invoked by uid 22791); 13 Sep 2009 02:41:27 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.25) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 13 Sep 2009 02:41:22 +0000 Received: from totara (42.63.255.123.dynamic.snap.net.nz [123.255.63.42]) by viper.snap.net.nz (Postfix) with ESMTP id C0A283DB4DA; Sun, 13 Sep 2009 14:41:19 +1200 (NZST) Received: by totara (Postfix, from userid 1000) id 6B5EFC164; Sun, 13 Sep 2009 14:41:18 +1200 (NZST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19116.23500.574462.227048@totara.tehura.co.nz> Date: Sun, 13 Sep 2009 02:41:00 -0000 To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: Patch: implement new dynamic varobj spec From: nickrob@snap.net.nz (Nick Roberts) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00379.txt.bz2 > 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, std::allocator >",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, std::allocator >",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);