This is the mail archive of the
mailing list for the GDB project.
RFC: how to handle mutable types in varobj?
- From: Joel Brobecker <brobecker at adacore dot com>
- To: gdb-patches at sourceware dot org, vladimir at codesourcery dot com
- Cc: Tom Tromey <tromey at redhat dot com>
- Date: Wed, 28 Dec 2011 19:59:43 +0400
- Subject: RFC: how to handle mutable types in varobj?
I'd like to discuss how mutable types should be handled in varobj.
Here is one example involving Ada, but perhaps some other languages
have them too. So, consider the case of a variant record, declared
type Variant (Disc : Boolean := True) is
A : Integer;
case Disc is
when True =>
Yes : Boolean;
No : Boolean;
when False =>
D : Integer;
This is a record where the number of components depends on the value
of the discriminant (`Disc' in this case). If the discrimant is True,
it has 4 components: `Disc', `A', as well as `Yes' and `No'. But if
the discriminant is False, it only has 3 components now: `Disc' and
`A', as before, and now `D'.
The trouble with varobj starts when the value of the discriminant
changes during the lifetime of the variable, which is legal in this
case. If I create a varobj with a variable whose discrimant is True,
then step a few lines until the discriminant changes, and then request
an update, what should happen? In particular, if I had also listed
the varobj's children, what should happen of them?
In this situation, we go from a varobj with 4 children, to a varobj
with 3 children, 2 of them still having the same type, two old
children having disappeared, and one new child having appeared.
At the front-end level, what should we display at the end of the
-var-update command? We have several elements to consider:
(1) The root varobj itself
I imagine that this varobj should be listed in the changed list.
As far as I can tell from the documentation, probably with
the `type_changed' attribute, and probably the new number of
(2) The "unchanged" children `Disc' and `A', whose type have changed.
(3) The children varobj that have now disappeared.
Should the front-end be told somehow that they have disappeared?
Or do they infer this from the `type_changed' attribute?
(4) The new children varobj
I don't think they should be listed in the changed list,
since their value is new.
The thing is, I am wondering if we should include any of the varobj's
children at all. Whether listing (1) with `type_changed' would be
Purely based on the reading of the documentation and then the code,
I think that mutable types haven't been considered in the original
design - although perhaps the authors of the original design aren't
around anymore. It also seems that support for Python pretty-printing
has been crafted on to varobj, and indirectly introduced the notion
of dynamicity, which is probably similar in some ways to our mutability.
But I am also guessing that this support was implemented in a way
that kept things compatible at the GDB/MI level. As a result, I am
having a hard time building a good overal picture of how things work,
partly because there are so many flags: children_requested, from, to,
type_changed, updated, changedm children_changed, etc.
Rather than redesign the whole thing, I am wondering if we can
expand a little bit on the Python dynamic properties and create
the notion of mutability that we could use for both types that
have a pretty-printer as well as types that are genuinely mutable.