[commit] Make "struct value" opaque

[Andrew Cagney <cagney at gnu dot org>]

ya! committed,
Andrew

2005-02-08  Andrew Cagney  <cagney@gnu.org>

	* value.c (struct value): Move to here ...
	* value.h (struct value): ... from here.  Copy comments to
	corresponding function declarations, re-order.
 
Index: value.c
===================================================================
RCS file: /cvs/src/src/gdb/value.c,v
retrieving revision 1.22
diff -p -u -r1.22 value.c
--- value.c	8 Feb 2005 04:57:03 -0000	1.22
+++ value.c	8 Feb 2005 05:38:02 -0000
@@ -42,6 +42,139 @@
 
 void _initialize_values (void);
 
+struct value
+{
+  /* Type of value; either not an lval, or one of the various
+     different possible kinds of lval.  */
+  enum lval_type lval;
+
+  /* Is it modifiable?  Only relevant if lval != not_lval.  */
+  int modifiable;
+
+  /* Location of value (if lval).  */
+  union
+  {
+    /* If lval == lval_memory, this is the address in the inferior.
+       If lval == lval_register, this is the byte offset into the
+       registers structure.  */
+    CORE_ADDR address;
+
+    /* Pointer to internal variable.  */
+    struct internalvar *internalvar;
+  } location;
+
+  /* Describes offset of a value within lval of a structure in bytes.
+     If lval == lval_memory, this is an offset to the address.  If
+     lval == lval_register, this is a further offset from
+     location.address within the registers structure.  Note also the
+     member embedded_offset below.  */
+  int offset;
+
+  /* Only used for bitfields; number of bits contained in them.  */
+  int bitsize;
+
+  /* Only used for bitfields; position of start of field.  For
+     BITS_BIG_ENDIAN=0 targets, it is the position of the LSB.  For
+     BITS_BIG_ENDIAN=1 targets, it is the position of the MSB. */
+  int bitpos;
+
+  /* Frame register value is relative to.  This will be described in
+     the lval enum above as "lval_register".  */
+  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.  */
+  struct type *enclosing_type;
+  int embedded_offset;
+  int pointed_to_offset;
+
+  /* Values are stored in a chain, so that they can be deleted easily
+     over calls to the inferior.  Values assigned to internal
+     variables or put into the value history are taken off this
+     list.  */
+  struct value *next;
+
+  /* Register number if the value is from a register.  */
+  short regnum;
+
+  /* If zero, contents of this value are in the contents field.  If
+     nonzero, contents are in inferior memory at address in the
+     location.address field plus the offset field (and the lval field
+     should be lval_memory).
+
+     WARNING: This field is used by the code which handles watchpoints
+     (see breakpoint.c) to decide whether a particular value can be
+     watched by hardware watchpoints.  If the lazy flag is set for
+     some member of a value chain, it is assumed that this member of
+     the chain doesn't need to be watched as part of watching the
+     value itself.  This is how GDB avoids watching the entire struct
+     or array when the user wants to watch a single struct member or
+     array element.  If you ever change the way lazy flag is set and
+     reset, be sure to consider this use as well!  */
+  char lazy;
+
+  /* If nonzero, this is the value of a variable which does not
+     actually exist in the program.  */
+  char optimized_out;
+
+  /* Actual contents of the value.  For use of this value; setting it
+     uses the stuff above.  Not valid if lazy is nonzero.  Target
+     byte-order.  We force it to be aligned properly for any possible
+     value.  Note that a value therefore extends beyond what is
+     declared here.  */
+  union
+  {
+    bfd_byte contents[1];
+    DOUBLEST force_doublest_align;
+    LONGEST force_longest_align;
+    CORE_ADDR force_core_addr_align;
+    void *force_pointer_align;
+  } aligner;
+  /* Do not add any new members here -- contents above will trash
+     them.  */
+};
+
 /* Prototypes for local functions. */
 
 static void show_values (char *, int);
Index: value.h
===================================================================
RCS file: /cvs/src/src/gdb/value.h,v
retrieving revision 1.80
diff -p -u -r1.80 value.h
--- value.h	8 Feb 2005 04:57:03 -0000	1.80
+++ value.h	8 Feb 2005 05:38:02 -0000
@@ -39,166 +39,118 @@ struct ui_file;
    inferior (i.e. to be put into the history list or an internal
    variable).  */
 
-struct value
-{
-  /* Type of value; either not an lval, or one of the various
-     different possible kinds of lval.  */
-  enum lval_type lval;
-
-  /* Is it modifiable?  Only relevant if lval != not_lval.  */
-  int modifiable;
-
-  /* Location of value (if lval).  */
-  union
-  {
-    /* If lval == lval_memory, this is the address in the inferior.
-       If lval == lval_register, this is the byte offset into the
-       registers structure.  */
-    CORE_ADDR address;
-
-    /* Pointer to internal variable.  */
-    struct internalvar *internalvar;
-  } location;
-
-  /* Describes offset of a value within lval of a structure in bytes.
-     If lval == lval_memory, this is an offset to the address.  If
-     lval == lval_register, this is a further offset from
-     location.address within the registers structure.  Note also the
-     member embedded_offset below.  */
-  int offset;
-
-  /* Only used for bitfields; number of bits contained in them.  */
-  int bitsize;
-
-  /* Only used for bitfields; position of start of field.  For
-     BITS_BIG_ENDIAN=0 targets, it is the position of the LSB.  For
-     BITS_BIG_ENDIAN=1 targets, it is the position of the MSB. */
-  int bitpos;
-
-  /* Frame register value is relative to.  This will be described in
-     the lval enum above as "lval_register".  */
-  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.  */
-  struct type *enclosing_type;
-  int embedded_offset;
-  int pointed_to_offset;
-
-  /* Values are stored in a chain, so that they can be deleted easily
-     over calls to the inferior.  Values assigned to internal
-     variables or put into the value history are taken off this
-     list.  */
-  struct value *next;
-
-  /* Register number if the value is from a register.  */
-  short regnum;
-
-  /* If zero, contents of this value are in the contents field.  If
-     nonzero, contents are in inferior memory at address in the
-     location.address field plus the offset field (and the lval field
-     should be lval_memory).
-
-     WARNING: This field is used by the code which handles watchpoints
-     (see breakpoint.c) to decide whether a particular value can be
-     watched by hardware watchpoints.  If the lazy flag is set for
-     some member of a value chain, it is assumed that this member of
-     the chain doesn't need to be watched as part of watching the
-     value itself.  This is how GDB avoids watching the entire struct
-     or array when the user wants to watch a single struct member or
-     array element.  If you ever change the way lazy flag is set and
-     reset, be sure to consider this use as well!  */
-  char lazy;
-
-  /* If nonzero, this is the value of a variable which does not
-     actually exist in the program.  */
-  char optimized_out;
-
-  /* Actual contents of the value.  For use of this value; setting it
-     uses the stuff above.  Not valid if lazy is nonzero.  Target
-     byte-order.  We force it to be aligned properly for any possible
-     value.  Note that a value therefore extends beyond what is
-     declared here.  */
-  union
-  {
-    bfd_byte contents[1];
-    DOUBLEST force_doublest_align;
-    LONGEST force_longest_align;
-    CORE_ADDR force_core_addr_align;
-    void *force_pointer_align;
-  } aligner;
-  /* Do not add any new members here -- contents above will trash
-     them.  */
-};
+struct value;
 
 /* Values are stored in a chain, so that they can be deleted easily
    over calls to the inferior.  Values assigned to internal variables
    or put into the value history are taken off this list.  */
+
 struct value *value_next (struct value *);
 
+/* Type of the value.  */
+
 extern struct type *value_type (struct value *);
+
 /* This is being used to change the type of an existing value, that
    code should instead be creating a new value with the changed type
    (but possibly shared content).  */
+
 extern void deprecated_set_value_type (struct value *value,
 				       struct type *type);
+
+/* Only used for bitfields; number of bits contained in them.  */
+
 extern int value_bitsize (struct value *);
 extern void set_value_bitsize (struct value *, int bit);
+
+/* Only used for bitfields; position of start of field.  For
+   BITS_BIG_ENDIAN=0 targets, it is the position of the LSB.  For
+   BITS_BIG_ENDIAN=1 targets, it is the position of the MSB.  */
+
 extern int value_bitpos (struct value *);
 extern void set_value_bitpos (struct value *, int bit);
 
+/* Describes offset of a value within lval of a structure in bytes.
+   If lval == lval_memory, this is an offset to the address.  If lval
+   == lval_register, this is a further offset from location.address
+   within the registers structure.  Note also the member
+   embedded_offset below.  */
+
 extern int value_offset (struct value *);
 extern void set_value_offset (struct value *, int offset);
 
 /* The comment from "struct value" reads: ``Is it modifiable?  Only
    relevant if lval != not_lval.''.  Shouldn't the value instead be
    not_lval and be done with it?  */
+
 extern int deprecated_value_modifiable (struct value *value);
 extern void deprecated_set_value_modifiable (struct value *value,
 					     int modifiable);
 
+/* 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.  */
+
 extern struct type *value_enclosing_type (struct value *);
+extern struct value *value_change_enclosing_type (struct value *val,
+						  struct type *new_type);
+extern int value_pointed_to_offset (struct value *value);
+extern void set_value_pointed_to_offset (struct value *value, int val);
+extern int value_embedded_offset (struct value *value);
+extern void set_value_embedded_offset (struct value *value, int val);
+
+/* If zero, contents of this value are in the contents field.  If
+   nonzero, contents are in inferior memory at address in the
+   location.address field plus the offset field (and the lval field
+   should be lval_memory).
+
+   WARNING: This field is used by the code which handles watchpoints
+   (see breakpoint.c) to decide whether a particular value can be
+   watched by hardware watchpoints.  If the lazy flag is set for some
+   member of a value chain, it is assumed that this member of the
+   chain doesn't need to be watched as part of watching the value
+   itself.  This is how GDB avoids watching the entire struct or array
+   when the user wants to watch a single struct member or array
+   element.  If you ever change the way lazy flag is set and reset, be
+   sure to consider this use as well!  */
+
 extern int value_lazy (struct value *);
 extern void set_value_lazy (struct value *value, int val);
 
@@ -217,6 +169,13 @@ extern void set_value_lazy (struct value
    something embedded in a larger run-time object.  */
 
 extern bfd_byte *value_contents_raw (struct value *);
+
+/* Actual contents of the value.  For use of this value; setting it
+   uses the stuff above.  Not valid if lazy is nonzero.  Target
+   byte-order.  We force it to be aligned properly for any possible
+   value.  Note that a value therefore extends beyond what is
+   declared here.  */
+
 extern const bfd_byte *value_contents (struct value *);
 extern bfd_byte *value_contents_writeable (struct value *);
 
@@ -228,24 +187,35 @@ extern const bfd_byte *value_contents_al
 
 extern int value_fetch_lazy (struct value *val);
 
+/* If nonzero, this is the value of a variable which does not actually
+   exist in the program.  */
 extern int value_optimized_out (struct value *value);
 extern void set_value_optimized_out (struct value *value, int val);
-extern int value_embedded_offset (struct value *value);
-extern void set_value_embedded_offset (struct value *value, int val);
-extern int value_pointed_to_offset (struct value *value);
-extern void set_value_pointed_to_offset (struct value *value, int val);
 
 /* While the following fields are per- VALUE .CONTENT .PIECE (i.e., a
    single value might have multiple LVALs), this hacked interface is
    limited to just the first PIECE.  Expect further change.  */
+/* Type of value; either not an lval, or one of the various different
+   possible kinds of lval.  */
 extern enum lval_type *deprecated_value_lval_hack (struct value *);
 #define VALUE_LVAL(val) (*deprecated_value_lval_hack (val))
+
+/* If lval == lval_memory, this is the address in the inferior.  If
+   lval == lval_register, this is the byte offset into the registers
+   structure.  */
 extern CORE_ADDR *deprecated_value_address_hack (struct value *);
 #define VALUE_ADDRESS(val) (*deprecated_value_address_hack (val))
+
+/* Pointer to internal variable.  */
 extern struct internalvar **deprecated_value_internalvar_hack (struct value *);
 #define VALUE_INTERNALVAR(val) (*deprecated_value_internalvar_hack (val))
+
+/* Frame register value is relative to.  This will be described in the
+   lval enum above as "lval_register".  */
 extern struct frame_id *deprecated_value_frame_id_hack (struct value *);
 #define VALUE_FRAME_ID(val) (*deprecated_value_frame_id_hack (val))
+
+/* Register number if the value is from a register.  */
 extern short *deprecated_value_regnum_hack (struct value *);
 #define VALUE_REGNUM(val) (*deprecated_value_regnum_hack (val))
 
@@ -330,9 +300,6 @@ extern struct value *allocate_value (str
 
 extern struct value *allocate_repeat_value (struct type *type, int count);
 
-extern struct value *value_change_enclosing_type (struct value *val,
-						  struct type *new_type);
-
 extern struct value *value_mark (void);
 
 extern void value_free_to_mark (struct value *mark);