gxxint.texi

gcc-2.95.3 Linux下最常用的C编译器

\input texinfo  @c -*-texinfo-*-
@c %**start of header 
@setfilename g++int.info
@settitle G++ internals
@setchapternewpage odd
@c %**end of header
     
@node Top, Limitations of g++, (dir), (dir)
@chapter Internal Architecture of the Compiler

This is meant to describe the C++ front-end for gcc in detail.
Questions and comments to Benjamin Kosnik @code{<bkoz@@cygnus.com>}.

@menu
* Limitations of g++::          
* Routines::                    
* Implementation Specifics::    
* Glossary::                    
* Macros::                      
* Typical Behavior::            
* Coding Conventions::          
* Templates::                   
* Access Control::              
* Error Reporting::             
* Parser::                      
* Exception Handling::          
* Free Store::                  
* Mangling::  Function name mangling for C++ and Java
* Vtables:: Two ways to do virtual functions
* Concept Index::               
@end menu

@node Limitations of g++, Routines, Top, Top
@section Limitations of g++

@itemize @bullet
@item
Limitations on input source code: 240 nesting levels with the parser
stacksize (YYSTACKSIZE) set to 500 (the default), and requires around
16.4k swap space per nesting level.  The parser needs about 2.09 *
number of nesting levels worth of stackspace.

@cindex pushdecl_class_level
@item
I suspect there are other uses of pushdecl_class_level that do not call
set_identifier_type_value in tandem with the call to
pushdecl_class_level.  It would seem to be an omission.

@cindex access checking
@item
Access checking is unimplemented for nested types.

@cindex @code{volatile}
@item
@code{volatile} is not implemented in general.

@end itemize

@node Routines, Implementation Specifics, Limitations of g++, Top
@section Routines

This section describes some of the routines used in the C++ front-end.

@code{build_vtable} and @code{prepare_fresh_vtable} is used only within
the @file{cp-class.c} file, and only in @code{finish_struct} and
@code{modify_vtable_entries}.

@code{build_vtable}, @code{prepare_fresh_vtable}, and
@code{finish_struct} are the only routines that set @code{DECL_VPARENT}.

@code{finish_struct} can steal the virtual function table from parents,
this prohibits related_vslot from working.  When finish_struct steals,
we know that

@example
get_binfo (DECL_FIELD_CONTEXT (CLASSTYPE_VFIELD (t)), t, 0)
@end example

@noindent
will get the related binfo.

@code{layout_basetypes} does something with the VIRTUALS.

Supposedly (according to Tiemann) most of the breadth first searching
done, like in @code{get_base_distance} and in @code{get_binfo} was not
because of any design decision.  I have since found out the at least one
part of the compiler needs the notion of depth first binfo searching, I
am going to try and convert the whole thing, it should just work.  The
term left-most refers to the depth first left-most node.  It uses
@code{MAIN_VARIANT == type} as the condition to get left-most, because
the things that have @code{BINFO_OFFSET}s of zero are shared and will
have themselves as their own @code{MAIN_VARIANT}s.  The non-shared right
ones, are copies of the left-most one, hence if it is its own
@code{MAIN_VARIANT}, we know it IS a left-most one, if it is not, it is
a non-left-most one.

@code{get_base_distance}'s path and distance matters in its use in:

@itemize @bullet
@item
@code{prepare_fresh_vtable} (the code is probably wrong)
@item
@code{init_vfields} Depends upon distance probably in a safe way,
build_offset_ref might use partial paths to do further lookups,
hack_identifier is probably not properly checking access.

@item
@code{get_first_matching_virtual} probably should check for
@code{get_base_distance} returning -2.

@item
@code{resolve_offset_ref} should be called in a more deterministic
manner.  Right now, it is called in some random contexts, like for
arguments at @code{build_method_call} time, @code{default_conversion}
time, @code{convert_arguments} time, @code{build_unary_op} time,
@code{build_c_cast} time, @code{build_modify_expr} time,
@code{convert_for_assignment} time, and
@code{convert_for_initialization} time.

But, there are still more contexts it needs to be called in, one was the
ever simple:

@example
if (obj.*pmi != 7)
   @dots{}
@end example

Seems that the problems were due to the fact that @code{TREE_TYPE} of
the @code{OFFSET_REF} was not a @code{OFFSET_TYPE}, but rather the type
of the referent (like @code{INTEGER_TYPE}).  This problem was fixed by
changing @code{default_conversion} to check @code{TREE_CODE (x)},
instead of only checking @code{TREE_CODE (TREE_TYPE (x))} to see if it
was @code{OFFSET_TYPE}.

@end itemize

@node Implementation Specifics, Glossary, Routines, Top
@section Implementation Specifics

@itemize @bullet
@item Explicit Initialization

The global list @code{current_member_init_list} contains the list of
mem-initializers specified in a constructor declaration.  For example:

@example
foo::foo() : a(1), b(2) @{@}
@end example

@noindent
will initialize @samp{a} with 1 and @samp{b} with 2.
@code{expand_member_init} places each initialization (a with 1) on the
global list.  Then, when the fndecl is being processed,
@code{emit_base_init} runs down the list, initializing them.  It used to
be the case that g++ first ran down @code{current_member_init_list},
then ran down the list of members initializing the ones that weren't
explicitly initialized.  Things were rewritten to perform the
initializations in order of declaration in the class.  So, for the above
example, @samp{a} and @samp{b} will be initialized in the order that
they were declared:

@example
class foo @{ public: int b; int a; foo (); @};
@end example

@noindent
Thus, @samp{b} will be initialized with 2 first, then @samp{a} will be
initialized with 1, regardless of how they're listed in the mem-initializer.

@item The Explicit Keyword

The use of @code{explicit} on a constructor is used by @code{grokdeclarator}
to set the field @code{DECL_NONCONVERTING_P}.  That value is used by
@code{build_method_call} and @code{build_user_type_conversion_1} to decide
if a particular constructor should be used as a candidate for conversions.

@end itemize

@node Glossary, Macros, Implementation Specifics, Top
@section Glossary

@table @r
@item binfo
The main data structure in the compiler used to represent the
inheritance relationships between classes.  The data in the binfo can be
accessed by the BINFO_ accessor macros.

@item vtable
@itemx virtual function table

The virtual function table holds information used in virtual function
dispatching.  In the compiler, they are usually referred to as vtables,
or vtbls.  The first index is not used in the normal way, I believe it
is probably used for the virtual destructor. There are two forms of
virtual tables, one that has offsets in addition to pointers, and one
using thunks. @xref{Vtables}.

@item vfield

vfields can be thought of as the base information needed to build
vtables.  For every vtable that exists for a class, there is a vfield.
See also vtable and virtual function table pointer.  When a type is used
as a base class to another type, the virtual function table for the
derived class can be based upon the vtable for the base class, just
extended to include the additional virtual methods declared in the
derived class.  The virtual function table from a virtual base class is
never reused in a derived class.  @code{is_normal} depends upon this.

@item virtual function table pointer

These are @code{FIELD_DECL}s that are pointer types that point to
vtables.  See also vtable and vfield.
@end table

@node Macros, Typical Behavior, Glossary, Top
@section Macros

This section describes some of the macros used on trees.  The list
should be alphabetical.  Eventually all macros should be documented
here.

@table @code
@item 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


@item 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:

@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
@end example

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


@item 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.


@item 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


@item 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


@item 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.


@item 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.


@item 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
	

@item 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


@item 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:

@example
struct A
@{
  virtual int f ();
@};

struct B : A
@{
  int f ();
@};

DECL_CONTEXT (A::f) == A
DECL_CLASS_CONTEXT (A::f) == A