This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
[patch] clarify ``struct type . length''
- To: gdb-patches at sources dot redhat dot com
- Subject: [patch] clarify ``struct type . length''
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Mon, 20 Aug 2001 20:22:20 -0400
Hello,
I've checked the attatched in as an obvious fix. It clarifies the
length field of the ``struct type''.
Andrew
2001-08-20 Andrew Cagney <ac131313@redhat.com>
* gdbtypes.h (struct type): Clarify meaning of field ``length''.
Index: gdbtypes.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.h,v
retrieving revision 1.11
diff -p -r1.11 gdbtypes.h
*** gdbtypes.h 2001/07/08 20:42:15 1.11
--- gdbtypes.h 2001/08/21 00:19:03
*************** struct type
*** 231,243 ****
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
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
(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. */
--- 231,247 ----
char *tag_name;
! /* 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
(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. */