This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
as follow:

   type Variant (Disc : Boolean := True) is
      A : Integer;
      case Disc is
         when True =>
            Yes : Boolean;
            No : Boolean;
         when False =>
            D : Integer;
      end case;
   end record;

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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]