From: nickrob@snap.net.nz (Nick Roberts)
To: Tom Tromey <tromey@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: Patch: implement new dynamic varobj spec
Date: Sun, 13 Sep 2009 02:41:00 -0000 [thread overview]
Message-ID: <19116.23500.574462.227048@totara.tehura.co.nz> (raw)
> 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);
next reply other threads:[~2009-09-13 2:41 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-13 2:41 Nick Roberts [this message]
2009-09-14 20:12 ` Tom Tromey
2009-09-14 20:21 ` Tom Tromey
2009-09-15 0:03 ` Nick Roberts
2009-09-14 23:48 ` Nick Roberts
2009-09-15 15:38 ` Tom Tromey
-- strict thread matches above, loose matches on Subject: below --
2009-09-10 20:58 Tom Tromey
2009-09-11 5:41 ` Nick Roberts
2009-09-11 19:41 ` Tom Tromey
2009-09-11 20:49 ` Eli Zaretskii
2009-09-11 21:12 ` Tom Tromey
2009-09-12 8:08 ` Eli Zaretskii
2009-09-11 23:55 ` Nick Roberts
2009-09-14 19:59 ` Tom Tromey
2009-09-14 22:55 ` Nick Roberts
2009-09-15 15:37 ` Tom Tromey
2009-09-15 22:28 ` Nick Roberts
2009-09-16 5:45 ` Vladimir Prus
2009-09-16 9:56 ` Nick Roberts
2009-09-16 17:12 ` Tom Tromey
2009-09-16 22:26 ` Nick Roberts
2009-09-15 22:43 ` Nick Roberts
2009-09-16 5:39 ` Vladimir Prus
2009-09-16 9:36 ` Nick Roberts
2009-09-16 5:44 ` Vladimir Prus
2009-09-14 19:56 ` Tom Tromey
2009-09-12 9:18 ` Eli Zaretskii
2009-09-14 20:03 ` Tom Tromey
2009-09-14 20:22 ` Eli Zaretskii
2009-09-14 21:29 ` Tom Tromey
2009-09-15 3:06 ` Eli Zaretskii
2009-09-14 11:24 ` Vladimir Prus
2009-09-16 23:53 ` Tom Tromey
2009-09-16 5:46 ` Vladimir Prus
2009-09-19 12:01 ` Matt Rice
2009-09-19 15:59 ` Joel Brobecker
2009-09-14 20:05 ` Tom Tromey
2009-09-14 20:24 ` Eli Zaretskii
2009-09-14 23:58 ` Nick Roberts
2009-09-18 9:29 ` Vladimir Prus
2009-09-18 18:25 ` Tom Tromey
2009-09-19 12:57 ` Vladimir Prus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19116.23500.574462.227048@totara.tehura.co.nz \
--to=nickrob@snap.net.nz \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox