This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: how to handle mutable types in varobj?
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org, vladimir at codesourcery dot com
- Date: Tue, 3 Jan 2012 21:10:40 +0400
- Subject: Re: RFC: how to handle mutable types in varobj?
- References: <20111228155943.GD2632@adacore.com> <m3zke5kebm.fsf@fleche.redhat.com>
> Pedro> So, I factored out the "listing dynamic varobj's
> Pedro> children" code behind a common interface, making use of a new
> Pedro> iterator "virtual" object (struct varobj_iter), and reimplemented
> Pedro> both pretty-printing varobjs and available-children-only varobjs using
> Pedro> that same interface.
>
> Sounds nice.
I haven't had time to look at this lately. But it does sound nice.
On the other hand, Pedro's answers gave me an idea that sounds
obvious in retrospect. I tested how floating varobjs work in C:
I have two struct types, where the first couple of fields have
the same name and type. The last two change from one location
to the next. At the first location, I did:
| -var-create v @ v
| ^done,name="v",numchild="4",value="{...}",type="struct variant_1",thread-id="1",has_more="0"
| (gdb)
| -var-list-children 1 v
| ^done,numchild="4",children=[child={name="v.disc",exp="disc",numchild="0",value="1",type="int",thread-id="1"},child={name="v.a",exp="a",numchild="0",value="2",type="int",thread-id="1"},child={name="v.b",exp="b",numchild="0",value="3",type="int",thread-id="1"},child={name="v.c",exp="c",numchild="0",value="5",type="int",thread-id="1"}],has_more="0"
And then resumed the execution until reaching the second location,
where a -var-update * yields:
| -var-update 1 v
| ^done,changelist=[{name="v",value="{...}",in_scope="true",type_changed="true",new_type="struct variant_2",new_num_children="4",has_more="0"}]
As you can see, all children of v have disappeared.
So, as long as the front-end does not make the extra assumption
that type-changes only occur with floating varobjs, a first step
at implementing mutations could be done that way.
In the light of this, do you guys think that a patch along the lines
of what I sent would be acceptable?
http://www.sourceware.org/ml/gdb-patches/2011-12/msg00886.html
The gist of the change is a language-specific hook, and a couple of
blobs (one for root value, one for children values) that test for
mutation, and destroy children if detected.
As a second phase, we could try designing a little better how
dynamic objects behave. But I'd rather do something simple first,
familiarize myself with that, and then move on to a more difficult
project.
> I think the only caveat is that it has to be requested.
Another element that makes me think it's better to start simple
first.
> But, presumably Joel has a particular client in mind.
It's an Eclipse client. I'm not very familiar with any of them,
so I don't know how many instantiations of that project there are
out there.
I will check with the other engineer at AdaCore who looks at
this side of things, to see how he would react to non-floating
varobjs that mutate...
Cheers,
--
Joel