Re: RFC: how to handle mutable types in varobj?

[Joel Brobecker <brobecker@adacore.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