- /* 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;
-
- /* 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. */
+
+ /* 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. */