- /* Frame value is relative to. In practice, this address is only
- used if the value is stored in several registers in other than
- the current frame, and these registers have not all been saved
- at the same place in memory. This will be described in the
- lval enum above as "lval_reg_frame_relative". */
- CORE_ADDR frame_addr;
- /* Type of the value. */
- struct type *type;
- /* Type of the enclosing object if this is an embedded subobject.
- The member embedded_offset gives the real position of the subobject
- if type is not the same as enclosing_type.
-
- If the type field is a pointer type, then enclosing_type is
- a pointer type pointing to the real (enclosing) type of the target
- object. */
+
+ /* Frame value is relative to. In practice, this ID is only used if
+ the value is stored in several registers in other than the
+ current frame, and these registers have not all been saved at the
+ same place in memory. This will be described in the lval enum
+ above as "lval_reg_frame_relative". */
+ struct frame_id frame_id;
+
+ /* Type of the value. */
+ struct type *type;
+
+ /* If a value represents a C++ object, then the `type' field gives
+ the object's compile-time type. If the object actually belongs
+ to some class derived from `type', perhaps with other base
+ classes and additional members, then `type' is just a subobject
+ of the real thing, and the full object is probably larger than
+ `type' would suggest.
+
+ If `type' is a dynamic class (i.e. one with a vtable), then GDB
+ can actually determine the object's run-time type by looking at
+ the run-time type information in the vtable. When this
+ information is available, we may elect to read in the entire
+ object, for several reasons:
+
+ - When printing the value, the user would probably rather see the
+ full object, not just the limited portion apparent from the
+ compile-time type.
+
+ - If `type' has virtual base classes, then even printing `type'
+ alone may require reaching outside the `type' portion of the
+ object to wherever the virtual base class has been stored.
+
+ When we store the entire object, `enclosing_type' is the run-time
+ type -- the complete object -- and `embedded_offset' is the
+ offset of `type' within that larger type, in bytes. The
+ VALUE_CONTENTS macro takes `embedded_offset' into account, so
+ most GDB code continues to see the `type' portion of the value,
+ just as the inferior would.
+
+ If `type' is a pointer to an object, then `enclosing_type' is a
+ pointer to the object's run-time type, and `pointed_to_offset' is
+ the offset in bytes from the full object to the pointed-to object
+ -- that is, the value `embedded_offset' would have if we
+ followed the pointer and fetched the complete object. (I don't
+ really see the point. Why not just determine the run-time type
+ when you indirect, and avoid the special case? The contents
+ don't matter until you indirect anyway.)
+
+ If we're not doing anything fancy, `enclosing_type' is equal to
+ `type', and `embedded_offset' is zero, so everything works
+ normally. */