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

[Tom Tromey <tromey@redhat.com>]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> Purely based on the reading of the documentation and then the code,
Joel> I think that mutable types haven't been considered in the original
Joel> design

Yeah, I agree.  The weird access protection stuff makes me think that
perhaps C++ also wasn't considered -- IMNSHO this should be represented
via attributes on the various fields, not phony intermediate varobjs.

Joel> It also seems that support for Python pretty-printing
Joel> has been crafted on to varobj, and indirectly introduced the notion
Joel> of dynamicity, which is probably similar in some ways to our mutability.
Joel> But I am also guessing that this support was implemented in a way
Joel> that kept things compatible at the GDB/MI level. As a result, I am
Joel> having a hard time building a good overal picture of how things work,
Joel> partly because there are so many flags: children_requested, from, to,
Joel> type_changed, updated, changedm children_changed, etc.

The spaghetti is at least partly my fault.  Sorry about that.
TBH I found hacking varobj to be quite difficult.

You are right that dynamic varobjs were introduced to maintain
compatibility.  If the client does not send -enable-pretty-printing,
then no dynamic varobj will ever be created.  The idea is that dynamic
varobjs require some special client handling, so clients have to
explicitly request them.

Joel> The careful reader will also notice that I'm having trouble with
Joel> figuring out some invariants regarding the `from' and `to' fields
Joel> with respect to the `num_children' field... More stuff to be figured
Joel> out later...

'from' and 'to' are set by the MI client.  See -var-list-children and
-var-set-update-range.  I think these only really make sense for dynamic
varobjs, but maybe they work with any varobj, I don't recall.

I don't remember how 'num_children' is used any more.

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.

Pedro> Implementing Ada mutable types support through this would mean mutable
Pedro> varobjs would be exposed as dynamic=1 varobjs.  I'm not sure that'd be
Pedro> a problem?  With frontends that currently support dynamic varobjs,
Pedro> things should simply work.

I think the only caveat is that it has to be requested.
But, presumably Joel has a particular client in mind.
And, anyway, clients not supporting dynamic varobjs are really missing out.

Pedro> Non dynamic varobjs were kind of a mistake
Pedro> anyway (a !dynamic varobj that is bound to an 10000000 element array
Pedro> is wholly fetched in gdb memory at once...).

Yeah.

Tom