Go forward to Typical Behavior.
Go backward to Glossary.
Go up to Top.
Macros
======
This section describes some of the macros used on trees. The list
should be alphabetical. Eventually all macros should be documented
here. There are some postscript drawings that can be used to better
understand from of the more complex data structures, contact Mike Stump
(`mrs@cygnus.com') for information about them.
`BINFO_BASETYPES'
A vector of additional binfos for the types inherited by this
basetype. The binfos are fully unshared (except for virtual
bases, in which case the binfo structure is shared).
If this basetype describes type D as inherited in C, and if the
basetypes of D are E anf F, then this vector contains binfos
for inheritance of E and F by C.
Has values of:
TREE_VECs
`BINFO_INHERITANCE_CHAIN'
Temporarily used to represent specific inheritances. It usually
points to the binfo associated with the lesser derived type, but
it can be reversed by reverse_path. For example:
Z ZbY least derived
|
Y YbX
|
X Xb most derived
TYPE_BINFO (X) == Xb
BINFO_INHERITANCE_CHAIN (Xb) == YbX
BINFO_INHERITANCE_CHAIN (Yb) == ZbY
BINFO_INHERITANCE_CHAIN (Zb) == 0
Not sure is the above is really true, get_base_distance has is
point towards the most derived type, opposite from above.
Set by build_vbase_path, recursive_bounded_basetype_p,
get_base_distance, lookup_field, lookup_fnfields, and reverse_path.
What things can this be used on:
TREE_VECs that are binfos
`BINFO_OFFSET'
The offset where this basetype appears in its containing type.
BINFO_OFFSET slot holds the offset (in bytes) from the base of the
complete object to the base of the part of the object that is
allocated on behalf of this `type'. This is always 0 except when
there is multiple inheritance.
Used on TREE_VEC_ELTs of the binfos BINFO_BASETYPES (...) for
example.
`BINFO_VIRTUALS'
A unique list of functions for the virtual function table. See
also TYPE_BINFO_VIRTUALS.
What things can this be used on:
TREE_VECs that are binfos
`BINFO_VTABLE'
Used to find the VAR_DECL that is the virtual function table
associated with this binfo. See also TYPE_BINFO_VTABLE. To get
the virtual function table pointer, see CLASSTYPE_VFIELD.
What things can this be used on:
TREE_VECs that are binfos
Has values of:
VAR_DECLs that are virtual function tables
`BLOCK_SUPERCONTEXT'
In the outermost scope of each function, it points to the
FUNCTION_DECL node. It aids in better DWARF support of inline
functions.
`CLASSTYPE_TAGS'
CLASSTYPE_TAGS is a linked (via TREE_CHAIN) list of member classes
of a class. TREE_PURPOSE is the name, TREE_VALUE is the type
(pushclass scans these and calls pushtag on them.)
finish_struct scans these to produce TYPE_DECLs to add to the
TYPE_FIELDS of the type.
It is expected that name found in the TREE_PURPOSE slot is unique,
resolve_scope_to_name is one such place that depends upon this
uniqueness.
`CLASSTYPE_METHOD_VEC'
The following is true after finish_struct has been called (on the
class?) but not before. Before finish_struct is called, things are
different to some extent. Contains a TREE_VEC of methods of the
class. The TREE_VEC_LENGTH is the number of differently named
methods plus one for the 0th entry. The 0th entry is always
allocated, and reserved for ctors and dtors. If there are none,
TREE_VEC_ELT(N,0) == NULL_TREE. Each entry of the TREE_VEC is a
FUNCTION_DECL. For each FUNCTION_DECL, there is a DECL_CHAIN
slot. If the FUNCTION_DECL is the last one with a given name, the
DECL_CHAIN slot is NULL_TREE. Otherwise it is the next method
that has the same name (but a different signature). It would seem
that it is not true that because the DECL_CHAIN slot is used in
this way, we cannot call pushdecl to put the method in the global
scope (cause that would overwrite the TREE_CHAIN slot), because
they use different _CHAINs. finish_struct_methods setups up one
version of the TREE_CHAIN slots on the FUNCTION_DECLs.
friends are kept in TREE_LISTs, so that there's no need to use
their TREE_CHAIN slot for anything.
Has values of:
TREE_VECs
`CLASSTYPE_VFIELD'
Seems to be in the process of being renamed TYPE_VFIELD. Use on
types to get the main virtual function table pointer. To get the
virtual function table use BINFO_VTABLE (TYPE_BINFO ()).
Has values of:
FIELD_DECLs that are virtual function table pointers
What things can this be used on:
RECORD_TYPEs
`DECL_CLASS_CONTEXT'
Identifies the context that the _DECL was found in. For virtual
function tables, it points to the type associated with the virtual
function table. See also DECL_CONTEXT, DECL_FIELD_CONTEXT and
DECL_FCONTEXT.
The difference between this and DECL_CONTEXT, is that for virtuals
functions like:
struct A
{
virtual int f ();
};
struct B : A
{
int f ();
};
DECL_CONTEXT (A::f) == A
DECL_CLASS_CONTEXT (A::f) == A
DECL_CONTEXT (B::f) == A
DECL_CLASS_CONTEXT (B::f) == B
Has values of:
RECORD_TYPEs, or UNION_TYPEs
What things can this be used on:
TYPE_DECLs, _DECLs
`DECL_CONTEXT'
Identifies the context that the _DECL was found in. Can be used on
virtual function tables to find the type associated with the
virtual function table, but since they are FIELD_DECLs,
DECL_FIELD_CONTEXT is a better access method. Internally the same
as DECL_FIELD_CONTEXT, so don't us both. See also
DECL_FIELD_CONTEXT, DECL_FCONTEXT and DECL_CLASS_CONTEXT.
Has values of:
RECORD_TYPEs
What things can this be used on:
VAR_DECLs that are virtual function tables
_DECLs
`DECL_FIELD_CONTEXT'
Identifies the context that the FIELD_DECL was found in.
Internally the same as DECL_CONTEXT, so don't us both. See also
DECL_CONTEXT, DECL_FCONTEXT and DECL_CLASS_CONTEXT.
Has values of:
RECORD_TYPEs
What things can this be used on:
FIELD_DECLs that are virtual function pointers
FIELD_DECLs
`DECL_NESTED_TYPENAME'
Holds the fully qualified type name. Example, Base::Derived.
Has values of:
IDENTIFIER_NODEs
What things can this be used on:
TYPE_DECLs
`DECL_NAME'
Has values of:
0 for things that don't have names
IDENTIFIER_NODEs for TYPE_DECLs
`DECL_IGNORED_P'
A bit that can be set to inform the debug information output
routines in the back-end that a certain _DECL node should be
totally ignored.
Used in cases where it is known that the debugging information
will be output in another file, or where a sub-type is known not
to be needed because the enclosing type is not needed.
A compiler constructed virtual destructor in derived classes that
do not define an explicit destructor that was defined explicit in
a base class has this bit set as well. Also used on __FUNCTION__
and __PRETTY_FUNCTION__ to mark they are "compiler generated."
c-decl and c-lex.c both want DECL_IGNORED_P set for "internally
generated vars," and "user-invisible variable."
Functions built by the C++ front-end such as default destructors,
virtual destructors and default constructors want to be marked that
they are compiler generated, but unsure why.
Currently, it is used in an absolute way in the C++ front-end, as
an optimization, to tell the debug information output routines to
not generate debugging information that will be output by another
separately compiled file.
`DECL_VIRTUAL_P'
A flag used on FIELD_DECLs and VAR_DECLs. (Documentation in
tree.h is wrong.) Used in VAR_DECLs to indicate that the variable
is a vtable. It is also used in FIELD_DECLs for vtable pointers.
What things can this be used on:
FIELD_DECLs and VAR_DECLs
`DECL_VPARENT'
Used to point to the parent type of the vtable if there is one,
else it is just the type associated with the vtable. Because of
the sharing of virtual function tables that goes on, this slot is
not very useful, and is in fact, not used in the compiler at all.
It can be removed.
What things can this be used on:
VAR_DECLs that are virtual function tables
Has values of:
RECORD_TYPEs maybe UNION_TYPEs
`DECL_FCONTEXT'
Used to find the first baseclass in which this FIELD_DECL is
defined. See also DECL_CONTEXT, DECL_FIELD_CONTEXT and
DECL_CLASS_CONTEXT.
How it is used:
Used when writing out debugging information about vfield and vbase
decls.
What things can this be used on:
FIELD_DECLs that are virtual function pointers FIELD_DECLs
`DECL_REFERENCE_SLOT'
Used to hold the initialize for the reference.
What things can this be used on:
PARM_DECLs and VAR_DECLs that have a reference type
`DECL_VINDEX'
Used for FUNCTION_DECLs in two different ways. Before the
structure containing the FUNCTION_DECL is laid out, DECL_VINDEX
may point to a FUNCTION_DECL in a base class which is the
FUNCTION_DECL which this FUNCTION_DECL will replace as a virtual
function. When the class is laid out, this pointer is changed to
an INTEGER_CST node which is suitable to find an index into the
virtual function table. See get_vtable_entry as to how one can
find the right index into the virtual function table. The first
index 0, of a virtual function table it not used in the normal
way, so the first real index is 1.
DECL_VINDEX may be a TREE_LIST, that would seem to be a list of
overridden FUNCTION_DECLs. add_virtual_function has code to deal
with this when it uses the variable base_fndecl_list, but it would
seem that somehow, it is possible for the TREE_LIST to pursist
until method_call, and it should not.
What things can this be used on:
FUNCTION_DECLs
`DECL_SOURCE_FILE'
Identifies what source file a particular declaration was found in.
Has values of:
"<built-in>" on TYPE_DECLs to mean the typedef is built in
`DECL_SOURCE_LINE'
Identifies what source line number in the source file the
declaration was found at.
Has values of:
0 for an undefined label
0 for TYPE_DECLs that are internally generated
0 for FUNCTION_DECLs for functions generated by the compiler
(not yet, but should be)
0 for ``magic'' arguments to functions, that the user has no
control over
`TREE_USED'
Has values of:
0 for unused labels
`TREE_ADDRESSABLE'
A flag that is set for any type that has a constructor.
`TREE_COMPLEXITY'
They seem a kludge way to track recursion, poping, and pushing.
They only appear in cp-decl.c and cp-decl2.c, so the are a good
candidate for proper fixing, and removal.
`TREE_PRIVATE'
Set for FIELD_DECLs by finish_struct. But not uniformly set.
The following routines do something with PRIVATE access:
build_method_call, alter_access, finish_struct_methods,
finish_struct, convert_to_aggr, CWriteLanguageDecl,
CWriteLanguageType, CWriteUseObject, compute_access, lookup_field,
dfs_pushdecl, GNU_xref_member, dbxout_type_fields,
dbxout_type_method_1
`TREE_PROTECTED'
The following routines do something with PROTECTED access:
build_method_call, alter_access, finish_struct, convert_to_aggr,
CWriteLanguageDecl, CWriteLanguageType, CWriteUseObject,
compute_access, lookup_field, GNU_xref_member, dbxout_type_fields,
dbxout_type_method_1
`TYPE_BINFO'
Used to get the binfo for the type.
Has values of:
TREE_VECs that are binfos
What things can this be used on:
RECORD_TYPEs
`TYPE_BINFO_BASETYPES'
See also BINFO_BASETYPES.
`TYPE_BINFO_VIRTUALS'
A unique list of functions for the virtual function table. See
also BINFO_VIRTUALS.
What things can this be used on:
RECORD_TYPEs
`TYPE_BINFO_VTABLE'
Points to the virtual function table associated with the given
type. See also BINFO_VTABLE.
What things can this be used on:
RECORD_TYPEs
Has values of:
VAR_DECLs that are virtual function tables
`TYPE_NAME'
Names the type.
Has values of:
0 for things that don't have names.
should be IDENTIFIER_NODE for RECORD_TYPEs UNION_TYPEs and
ENUM_TYPEs.
TYPE_DECL for RECORD_TYPEs, UNION_TYPEs and ENUM_TYPEs, but
shouldn't be.
TYPE_DECL for typedefs, unsure why.
What things can one use this on:
TYPE_DECLs
RECORD_TYPEs
UNION_TYPEs
ENUM_TYPEs
History:
It currently points to the TYPE_DECL for RECORD_TYPEs,
UNION_TYPEs and ENUM_TYPEs, but it should be history soon.
`TYPE_METHODS'
Synonym for `CLASSTYPE_METHOD_VEC'. Chained together with
`TREE_CHAIN'. `dbxout.c' uses this to get at the methods of a
class.
`TYPE_DECL'
Used to represent typedefs, and used to represent bindings layers.
Components:
DECL_NAME is the name of the typedef. For example, foo would be
found in the DECL_NAME slot when `typedef int foo;' is
seen.
DECL_SOURCE_LINE identifies what source line number in the source
file the declaration was found at. A value of 0 indicates that
this TYPE_DECL is just an internal binding layer marker, and does
not correspond to a user supplied typedef.
DECL_SOURCE_FILE
`TYPE_FIELDS'
A linked list (via `TREE_CHAIN') of member types of a class. The
list can contain `TYPE_DECL's, but there can also be other things
in the list apparently. See also `CLASSTYPE_TAGS'.
`TYPE_VIRTUAL_P'
A flag used on a `FIELD_DECL' or a `VAR_DECL', indicates it is a
virtual function table or a pointer to one. When used on a
`FUNCTION_DECL', indicates that it is a virtual function. When
used on an `IDENTIFIER_NODE', indicates that a function with this
same name exists and has been declared virtual.
When used on types, it indicates that the type has virtual
functions, or is derived from one that does.
Not sure if the above about virtual function tables is still true.
See also info on `DECL_VIRTUAL_P'.
What things can this be used on:
FIELD_DECLs, VAR_DECLs, FUNCTION_DECLs, IDENTIFIER_NODEs
`VF_BASETYPE_VALUE'
Get the associated type from the binfo that caused the given
vfield to exist. This is the least derived class (the most parent
class) that needed a virtual function table. It is probably the
case that all uses of this field are misguided, but they need to
be examined on a case-by-case basis. See history for more
information on why the previous statement was made.
Set at `finish_base_struct' time.
What things can this be used on:
TREE_LISTs that are vfields
History:
This field was used to determine if a virtual function table's
slot should be filled in with a certain virtual function, by
checking to see if the type returned by VF_BASETYPE_VALUE was a
parent of the context in which the old virtual function existed.
This incorrectly assumes that a given type _could_ not appear as a
parent twice in a given inheritance lattice. For single
inheritance, this would in fact work, because a type could not
possibly appear more than once in an inheritance lattice, but with
multiple inheritance, a type can appear more than once.
`VF_BINFO_VALUE'
Identifies the binfo that caused this vfield to exist. If this
vfield is from the first direct base class that has a virtual
function table, then VF_BINFO_VALUE is NULL_TREE, otherwise it
will be the binfo of the direct base where the vfield came from.
Can use `TREE_VIA_VIRTUAL' on result to find out if it is a
virtual base class. Related to the binfo found by
get_binfo (VF_BASETYPE_VALUE (vfield), t, 0)
where `t' is the type that has the given vfield.
get_binfo (VF_BASETYPE_VALUE (vfield), t, 0)
will return the binfo for the the given vfield.
May or may not be set at `modify_vtable_entries' time. Set at
`finish_base_struct' time.
What things can this be used on:
TREE_LISTs that are vfields
`VF_DERIVED_VALUE'
Identifies the type of the most derived class of the vfield,
excluding the the class this vfield is for.
Set at `finish_base_struct' time.
What things can this be used on:
TREE_LISTs that are vfields
`VF_NORMAL_VALUE'
Identifies the type of the most derived class of the vfield,
including the class this vfield is for.
Set at `finish_base_struct' time.
What things can this be used on:
TREE_LISTs that are vfields
`WRITABLE_VTABLES'
This is a option that can be defined when building the compiler,
that will cause the compiler to output vtables into the data
segment so that the vtables maybe written. This is undefined by
default, because normally the vtables should be unwritable.
People that implement object I/O facilities may, or people that
want to change the dynamic type of objects may want to have the
vtables writable. Another way of achieving this would be to make
a copy of the vtable into writable memory, but the drawback there
is that that method only changes the type for one object.