Update comments in struct value for non-8-bits architectures

gdb/ChangeLog:

	* value.c (struct value): Update comments.
This commit is contained in:
Simon Marchi
2015-07-28 11:01:49 -04:00
parent 2e0569314c
commit 3723fda829
2 changed files with 19 additions and 15 deletions

View File

@ -1,3 +1,7 @@
2015-07-28 Simon Marchi <simon.marchi@ericsson.com>
* value.c (struct value): Update comments.
2015-07-28 Simon Marchi <simon.marchi@ericsson.com> 2015-07-28 Simon Marchi <simon.marchi@ericsson.com>
* gdbtypes.c (type_length_units): New function. * gdbtypes.c (type_length_units): New function.

View File

@ -234,11 +234,11 @@ struct value
} computed; } computed;
} location; } location;
/* Describes offset of a value within lval of a structure in bytes. /* Describes offset of a value within lval of a structure in target
If lval == lval_memory, this is an offset to the address. If addressable memory units. If lval == lval_memory, this is an offset to
lval == lval_register, this is a further offset from the address. If lval == lval_register, this is a further offset from
location.address within the registers structure. Note also the location.address within the registers structure. Note also the member
member embedded_offset below. */ embedded_offset below. */
int offset; int offset;
/* Only used for bitfields; number of bits contained in them. */ /* Only used for bitfields; number of bits contained in them. */
@ -291,19 +291,19 @@ struct value
When we store the entire object, `enclosing_type' is the run-time When we store the entire object, `enclosing_type' is the run-time
type -- the complete object -- and `embedded_offset' is the type -- the complete object -- and `embedded_offset' is the
offset of `type' within that larger type, in bytes. The offset of `type' within that larger type, in target addressable memory
value_contents() macro takes `embedded_offset' into account, so units. The value_contents() macro takes `embedded_offset' into account,
most GDB code continues to see the `type' portion of the value, so most GDB code continues to see the `type' portion of the value, just
just as the inferior would. as the inferior would.
If `type' is a pointer to an object, then `enclosing_type' is a 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 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 the offset in target addressable memory units from the full object
-- that is, the value `embedded_offset' would have if we followed to the pointed-to object -- that is, the value `embedded_offset' would
the pointer and fetched the complete object. (I don't really see have if we followed the pointer and fetched the complete object.
the point. Why not just determine the run-time type when you (I don't really see the point. Why not just determine the
indirect, and avoid the special case? The contents don't matter run-time type when you indirect, and avoid the special case? The
until you indirect anyway.) contents don't matter until you indirect anyway.)
If we're not doing anything fancy, `enclosing_type' is equal to If we're not doing anything fancy, `enclosing_type' is equal to
`type', and `embedded_offset' is zero, so everything works `type', and `embedded_offset' is zero, so everything works