darkkirb/old-cross-binutils
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

* gdbtypes.h (struct type): Clarify meaning of field ``length''.

Browse source
This commit is contained in:
Andrew Cagney 2001-08-21 00:24:58 +00:00
parent ca3f769514
commit 1c72f9b0c4
2 changed files with 14 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
gdb/ChangeLog
View file

@ -1,3 +1,7 @@
2001-08-20 Andrew Cagney <ac131313@redhat.com>
* gdbtypes.h (struct type): Clarify meaning of field ``length''.
2001-08-17 Keith Seitz <keiths@redhat.com>
* varobj.c (varobj_update): Change first parameter to

16
gdb/gdbtypes.h
View file

@ -231,13 +231,17 @@ struct type
char *tag_name;
/* Length of storage for a value of this type. Various places pass
this to memcpy and such, meaning it must be in units of
HOST_CHAR_BIT. Various other places expect they can calculate
addresses by adding it and such, meaning it must be in units of
/* Length of storage for a value of this type. This is of length
of the type as defined by the debug info and not the length of
the value that resides within the type. For instance, an
i386-ext floating-point value only occupies 80 bits of what is
typically a 12 byte `long double'. Various places pass this to
memcpy and such, meaning it must be in units of HOST_CHAR_BIT.
Various other places expect they can calculate addresses by
adding it and such, meaning it must be in units of
TARGET_CHAR_BIT. For some DSP targets, in which HOST_CHAR_BIT
will (presumably) be 8 and TARGET_CHAR_BIT will be (say) 32, this
is a problem. One fix would be to make this field in bits
will (presumably) be 8 and TARGET_CHAR_BIT will be (say) 32,
this is a problem. One fix would be to make this field in bits
(requiring that it always be a multiple of HOST_CHAR_BIT and
TARGET_CHAR_BIT)--the other choice would be to make it
consistently in units of HOST_CHAR_BIT. */