mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-23 03:29:47 +08:00
Update comments in struct value for non-8-bits architectures
gdb/ChangeLog: * value.c (struct value): Update comments.
This commit is contained in:
@ -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.
|
||||||
|
30
gdb/value.c
30
gdb/value.c
@ -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
|
||||||
|
Reference in New Issue
Block a user