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: Tom Tromey <tromey at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org, vladimir at codesourcery dot com
- Date: Mon, 02 Jan 2012 14:02:53 -0700
- Subject: Re: RFC: how to handle mutable types in varobj?
- References: <20111228155943.GD2632@adacore.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