-#define TYPE_FLAG_INCOMPLETE (1 << 8)
-
-
-struct type
- {
-
- /* Code for kind of type */
-
- enum type_code code;
-
- /* Name of this type, or NULL if none.
-
- This is used for printing only, except by poorly designed C++ code.
- For looking up a name, look for a symbol in the VAR_NAMESPACE. */
-
- char *name;
-
- /* Tag name for this type, or NULL if none. This means that the
- name of the type consists of a keyword followed by the tag name.
- Which keyword is determined by the type code ("struct" for
- TYPE_CODE_STRUCT, etc.). As far as I know C/C++ are the only languages
- with this feature.
-
- This is used for printing only, except by poorly designed C++ code.
- For looking up a name, look for a symbol in the STRUCT_NAMESPACE.
- One more legitimate use is that if TYPE_FLAG_STUB is set, this is
- the name to use to look for definitions in other files. */
-
- 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. */
-
- unsigned length;
-
- /* FIXME, these should probably be restricted to a Fortran-specific
- field in some fashion. */
+#define TYPE_FLAG_INCOMPLETE (1 << 8)
+#define TYPE_INCOMPLETE(t) (TYPE_FLAGS (t) & TYPE_FLAG_INCOMPLETE)
+
+/* Instruction-space delimited type. This is for Harvard architectures
+ which have separate instruction and data address spaces (and perhaps
+ others).
+
+ GDB usually defines a flat address space that is a superset of the
+ architecture's two (or more) address spaces, but this is an extension
+ of the architecture's model.
+
+ If TYPE_FLAG_INST is set, an object of the corresponding type
+ resides in instruction memory, even if its address (in the extended
+ flat address space) does not reflect this.
+
+ Similarly, if TYPE_FLAG_DATA is set, then an object of the
+ corresponding type resides in the data memory space, even if
+ this is not indicated by its (flat address space) address.
+
+ If neither flag is set, the default space for functions / methods
+ is instruction space, and for data objects is data memory. */
+
+#define TYPE_FLAG_CODE_SPACE (1 << 9)
+#define TYPE_CODE_SPACE(t) (TYPE_INSTANCE_FLAGS (t) & TYPE_FLAG_CODE_SPACE)
+
+#define TYPE_FLAG_DATA_SPACE (1 << 10)
+#define TYPE_DATA_SPACE(t) (TYPE_INSTANCE_FLAGS (t) & TYPE_FLAG_DATA_SPACE)
+
+/* FIXME drow/2002-06-03: Only used for methods, but applies as well
+ to functions. */
+
+#define TYPE_FLAG_VARARGS (1 << 11)
+#define TYPE_VARARGS(t) (TYPE_FLAGS (t) & TYPE_FLAG_VARARGS)
+
+/* Identify a vector type. Gcc is handling this by adding an extra
+ attribute to the array type. We slurp that in as a new flag of a
+ type. This is used only in dwarf2read.c. */
+#define TYPE_FLAG_VECTOR (1 << 12)
+#define TYPE_VECTOR(t) (TYPE_FLAGS (t) & TYPE_FLAG_VECTOR)
+
+/* Address class flags. Some environments provide for pointers whose
+ size is different from that of a normal pointer or address types
+ where the bits are interpreted differently than normal addresses. The
+ TYPE_FLAG_ADDRESS_CLASS_n flags may be used in target specific
+ ways to represent these different types of address classes. */
+#define TYPE_FLAG_ADDRESS_CLASS_1 (1 << 13)
+#define TYPE_ADDRESS_CLASS_1(t) (TYPE_INSTANCE_FLAGS(t) \
+ & TYPE_FLAG_ADDRESS_CLASS_1)
+#define TYPE_FLAG_ADDRESS_CLASS_2 (1 << 14)
+#define TYPE_ADDRESS_CLASS_2(t) (TYPE_INSTANCE_FLAGS(t) \
+ & TYPE_FLAG_ADDRESS_CLASS_2)
+#define TYPE_FLAG_ADDRESS_CLASS_ALL (TYPE_FLAG_ADDRESS_CLASS_1 \
+ | TYPE_FLAG_ADDRESS_CLASS_2)
+#define TYPE_ADDRESS_CLASS_ALL(t) (TYPE_INSTANCE_FLAGS(t) \
+ & TYPE_FLAG_ADDRESS_CLASS_ALL)
+
+struct main_type
+{
+ /* Code for kind of type */
+
+ enum type_code code;
+
+ /* Name of this type, or NULL if none.
+
+ This is used for printing only, except by poorly designed C++ code.
+ For looking up a name, look for a symbol in the VAR_NAMESPACE. */
+
+ char *name;
+
+ /* Tag name for this type, or NULL if none. This means that the
+ name of the type consists of a keyword followed by the tag name.
+ Which keyword is determined by the type code ("struct" for
+ TYPE_CODE_STRUCT, etc.). As far as I know C/C++ are the only languages
+ with this feature.
+
+ This is used for printing only, except by poorly designed C++ code.
+ For looking up a name, look for a symbol in the STRUCT_NAMESPACE.
+ One more legitimate use is that if TYPE_FLAG_STUB is set, this is
+ the name to use to look for definitions in other files. */
+
+ char *tag_name;
+
+ /* Length of storage for a value of this type. This is what
+ sizeof(type) would return; use it for address arithmetic,
+ memory reads and writes, etc. This size includes padding. For
+ example, an i386 extended-precision floating point value really
+ only occupies ten bytes, but most ABI's declare its size to be
+ 12 bytes, to preserve alignment. A `struct type' representing
+ such a floating-point type would have a `length' value of 12,
+ even though the last two bytes are unused.
+
+ There's a bit of a host/target mess here, if you're concerned
+ about machines whose bytes aren't eight bits long, or who don't
+ have byte-addressed memory. Various places pass this to memcpy
+ and such, meaning it must be in units of host bytes. Various
+ other places expect they can calculate addresses by adding it
+ and such, meaning it must be in units of target bytes. 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. However, this would still fail to address
+ machines based on a ternary or decimal representation. */
+
+ unsigned length;
+
+ /* FIXME, these should probably be restricted to a Fortran-specific
+ field in some fashion. */