@chapter Internal Architecture of the Compiler
This is meant to describe the C++ front-end for gcc in detail.
-Questions and comments to mrs@@cygnus.com.
+Questions and comments to Benjamin Kosnik @code{<bkoz@@cygnus.com>}.
@menu
* Limitations of g++::
* Access Control::
* Error Reporting::
* Parser::
-* Copying Objects::
* Exception Handling::
* Free Store::
+* Mangling:: Function name mangling for C++ and Java
* Concept Index::
@end menu
@item
@code{volatile} is not implemented in general.
-@cindex pointers to members
-@item
-Pointers to members are only minimally supported, and there are places
-where the grammar doesn't even properly accept them yet.
-
-@cindex multiple inheritance
-@item
-@code{this} will be wrong in virtual members functions defined in a
-virtual base class, when they are overridden in a derived class, when
-called via a non-left most object.
-
-An example would be:
-
-@example
-extern "C" int printf(const char*, ...);
-struct A @{ virtual void f() @{ @} @};
-struct B : virtual A @{ int b; B() : b(0) @{@} void f() @{ b++; @} @};
-struct C : B @{@};
-struct D : B @{@};
-struct E : C, D @{@};
-int main()
-@{
- E e;
- C& c = e; D& d = e;
- c.f(); d.f();
- printf ("C::b = %d, D::b = %d\n", e.C::b, e.D::b);
- return 0;
-@}
-@end example
-
-This will print out 2, 0, instead of 1,1.
-
@end itemize
@node Routines, Implementation Specifics, Limitations of g++, Top
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_VARIENT}, we know it IS a left-most one, if it is not, it is
+@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:
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 Argument Matching
-
-In early 1993, the argument matching scheme in @sc{gnu} C++ changed
-significantly. The original code was completely replaced with a new
-method that will, hopefully, be easier to understand and make fixing
-specific cases much easier.
-
-The @samp{-fansi-overloading} option is used to enable the new code; at
-some point in the future, it will become the default behavior of the
-compiler.
-
-The file @file{cp-call.c} contains all of the new work, in the functions
-@code{rank_for_overload}, @code{compute_harshness},
-@code{compute_conversion_costs}, and @code{ideal_candidate}.
-
-Instead of using obscure numerical values, the quality of an argument
-match is now represented by clear, individual codes. The new data
-structure @code{struct harshness} (it used to be an @code{unsigned}
-number) contains:
-
-@enumerate a
-@item the @samp{code} field, to signify what was involved in matching two
-arguments;
-@item the @samp{distance} field, used in situations where inheritance
-decides which function should be called (one is ``closer'' than
-another);
-@item and the @samp{int_penalty} field, used by some codes as a tie-breaker.
-@end enumerate
-
-The @samp{code} field is a number with a given bit set for each type of
-code, OR'd together. The new codes are:
-
-@itemize @bullet
-@item @code{EVIL_CODE}
-The argument was not a permissible match.
-
-@item @code{CONST_CODE}
-Currently, this is only used by @code{compute_conversion_costs}, to
-distinguish when a non-@code{const} member function is called from a
-@code{const} member function.
-
-@item @code{ELLIPSIS_CODE}
-A match against an ellipsis @samp{...} is considered worse than all others.
-
-@item @code{USER_CODE}
-Used for a match involving a user-defined conversion.
+@item The Explicit Keyword
-@item @code{STD_CODE}
-A match involving a standard conversion.
-
-@item @code{PROMO_CODE}
-A match involving an integral promotion. For these, the
-@code{int_penalty} field is used to handle the ARM's rule (XXX cite)
-that a smaller @code{unsigned} type should promote to a @code{int}, not
-to an @code{unsigned int}.
-
-@item @code{QUAL_CODE}
-Used to mark use of qualifiers like @code{const} and @code{volatile}.
-
-@item @code{TRIVIAL_CODE}
-Used for trivial conversions. The @samp{int_penalty} field is used by
-@code{convert_harshness} to communicate further penalty information back
-to @code{build_overload_call_real} when deciding which function should
-be call.
-@end itemize
-
-The functions @code{convert_to_aggr} and @code{build_method_call} use
-@code{compute_conversion_costs} to rate each argument's suitability for
-a given candidate function (that's how we get the list of candidates for
-@code{ideal_candidate}).
+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
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
-understnad from of the more complex data structures, contact Mike Stump
-(@code{mrs@@cygnus.com}) for information about them.
+here.
@table @code
@item BINFO_BASETYPES
@end display
-@item 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
-
-
@item DECL_NAME
Has values of:
because the enclosing type is not needed.
A compiler constructed virtual destructor in derived classes that do not
-define an exlicit destructor that was defined exlicit in a base class
+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 desctructors and default constructors want to be marked that
+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
proper fixing, and removal.
+@item TREE_HAS_CONSTRUCTOR
+A flag to indicate when a CALL_EXPR represents a call to a constructor.
+If set, we know that the type of the object, is the complete type of the
+object, and that the value returned is nonnull. When used in this
+fashion, it is an optimization. Can also be used on SAVE_EXPRs to
+indicate when they are of fixed type and nonnull. Can also be used on
+INDIRECT_EXPRs on CALL_EXPRs that represent a call to a constructor.
+
+
@item TREE_PRIVATE
Set for FIELD_DECLs by finish_struct. But not uniformly set.
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 suppiled typedef.
+ marker, and does not correspond to a user supplied typedef.
DECL_SOURCE_FILE
@end example
@noindent
-will return the binfo for the the given vfield.
+will return the binfo for the given vfield.
May or may not be set at @code{modify_vtable_entries} time. Set at
@code{finish_base_struct} time.
@item VF_DERIVED_VALUE
Identifies the type of the most derived class of the vfield, excluding
-the the class this vfield is for.
+the class this vfield is for.
Set at @code{finish_base_struct} time.
@node Templates, Access Control, Coding Conventions, Top
@section Templates
-g++ uses the simple approach to instantiating templates: it blindly
-generates the code for each instantiation as needed. For class
-templates, g++ pushes the template parameters into the namespace for the
-duration of the instantiation; for function templates, it's a simple
-search and replace.
+A template is represented by a @code{TEMPLATE_DECL}. The specific
+fields used are:
-This approach does not support any of the template definition-time error
-checking that is being bandied about by X3J16. It makes no attempt to deal
-with name binding in a consistent way.
+@table @code
+@item DECL_TEMPLATE_RESULT
+The generic decl on which instantiations are based. This looks just
+like any other decl.
-Instantiation of a class template is triggered by the use of a template
-class anywhere but in a straight declaration like @code{class A<int>}.
-This is wrong; in fact, it should not be triggered by typedefs or
-declarations of pointers. Now that explicit instantiation is supported,
-this misfeature is not necessary.
+@item DECL_TEMPLATE_PARMS
+The parameters to this template.
+@end table
-Important functions:
+The generic decl is parsed as much like any other decl as possible,
+given the parameterization. The template decl is not built up until the
+generic decl has been completed. For template classes, a template decl
+is generated for each member function and static data member, as well.
-@table @code
-@item instantiate_class_template
-This function
-@end table
+Template members of template classes are represented by a TEMPLATE_DECL
+for the class' parameters around another TEMPLATE_DECL for the member's
+parameters.
+
+All declarations that are instantiations or specializations of templates
+refer to their template and parameters through DECL_TEMPLATE_INFO.
+
+How should I handle parsing member functions with the proper param
+decls? Set them up again or try to use the same ones? Currently we do
+the former. We can probably do this without any extra machinery in
+store_pending_inline, by deducing the parameters from the decl in
+do_pending_inlines. PRE_PARSED_TEMPLATE_DECL?
+
+If a base is a parm, we can't check anything about it. If a base is not
+a parm, we need to check it for name binding. Do finish_base_struct if
+no bases are parameterized (only if none, including indirect, are
+parms). Nah, don't bother trying to do any of this until instantiation
+-- we only need to do name binding in advance.
+
+Always set up method vec and fields, inc. synthesized methods. Really?
+We can't know the types of the copy folks, or whether we need a
+destructor, or can have a default ctor, until we know our bases and
+fields. Otherwise, we can assume and fix ourselves later. Hopefully.
@node Access Control, Error Reporting, Templates, Top
@section Access Control
DECL, use @code{cp_error_at} and its ilk; to indicate which argument you want,
use @code{%+D}, or it will default to the first.
-@node Parser, Copying Objects, Error Reporting, Top
+@node Parser, Exception Handling, Error Reporting, Top
@section Parser
Some comments on the parser:
Unlike the others, this ambiguity is not recognized by the Working Paper.
-@node Copying Objects, Exception Handling, Parser, Top
-@section Copying Objects
-
-The generated copy assignment operator in g++ does not currently do the
-right thing for multiple inheritance involving virtual bases; it just
-calls the copy assignment operators for its direct bases. What it
-should probably do is:
-
-1) Split up the copy assignment operator for all classes that have
-vbases into "copy my vbases" and "copy everything else" parts. Or do
-the trickiness that the constructors do to ensure that vbases don't get
-initialized by intermediate bases.
-
-2) Wander through the class lattice, find all vbases for which no
-intermediate base has a user-defined copy assignment operator, and call
-their "copy everything else" routines. If not all of my vbases satisfy
-this criterion, warn, because this may be surprising behavior.
-
-3) Call the "copy everything else" routine for my direct bases.
-
-If we only have one direct base, we can just foist everything off onto
-them.
-
-This issue is currently under discussion in the core reflector
-(2/28/94).
-
-@node Exception Handling, Free Store, Copying Objects, Top
+@node Exception Handling, Free Store, Parser, Top
@section Exception Handling
Note, exception handling in g++ is still under development.
The C++ front-end exceptions are mapping into the unwind-protect
semantics by the C++ front-end. The mapping is describe below.
-Objects with RTTI support should use the RTTI information to do mapping
-and checking. Objects without RTTI, like int and const char *, have to
-use another means of matching. Currently we use the normal mangling used in
-building functions names. Int's are "i", const char * is PCc, etc...
-
-Unfortunately, the standard allows standard type conversions on throw
-parameters so they can match catch handlers. This means we need a
-mechanism to handle type conversion at run time, ICK. I read this part
-again, and it appears that we only have to be able to do a few of the
-conversions at run time, so we should be ok.
+When -frtti is used, rtti is used to do exception object type checking,
+when it isn't used, the encoded name for the type of the object being
+thrown is used instead. All code that originates exceptions, even code
+that throws exceptions as a side effect, like dynamic casting, and all
+code that catches exceptions must be compiled with either -frtti, or
+-fno-rtti. It is not possible to mix rtti base exception handling
+objects with code that doesn't use rtti. The exceptions to this, are
+code that doesn't catch or throw exceptions, catch (...), and code that
+just rethrows an exception.
+
+Currently we use the normal mangling used in building functions names
+(int's are "i", const char * is PCc) to build the non-rtti base type
+descriptors for exception handling. These descriptors are just plain
+NULL terminated strings, and internally they are passed around as char
+*.
In C++, all cleanups should be protected by exception regions. The
region starts just after the reason why the cleanup is created has
the exception object, and nothing can overwrite it, once we start
throwing. The only bad part, is that the stack remains large.
-Flaws in g++'s exception handling. The stack pointer is restored from
-stack, we want to match rs6000, and propagate the stack pointer from
-time of throw, down, to the catch place.
-
-Only exact type matching of throw types works (references work also),
-catch variables cannot be used. Only works on a Sun sparc running SunOS
-4.1.x. Unwinding to outer catch clauses works. All temps and local
-variables are cleaned up in all unwinded scopes. Completed parts of
-partially constructed objects are not cleaned up. Don't expect
-exception handling to work right if you optimize, in fact the compiler
-will probably core dump. If two EH regions are the exact same size, the
-backend cannot tell which one is first. It punts by picking the last
-one, if they tie. This is usually right. We really should stick in a
-nop, if they are the same size.
-
-If we fall off the end of a series of catch blocks, we return to the
-flow of control in a normal fasion. But this is wrong, we should
-rethrow.
-
-When we invoke the copy constructor for an exception object because it
-is passed by value, and if we take a hit (exception) inside the copy
-constructor someplace, where do we go? I have tentatively choosen to
-not catch throws by the outer block at the same unwind level, if one
-exists, but rather to allow the frame to unwind into the next series of
-handlers, if any. If this is the wrong way to do it, we will need to
-protect the rest of the handler in some fashion. Maybe just changing
-the handler's handler to protect the whole series of handlers is the
-right way to go.
-
-The EH object is copied like it should be, if it is passed by value,
-otherwise we get a reference directly to it.
-
-EH objects make it through unwinding, but are subject to being
-overwritten as they are still past the top of stack. Don't throw
-automatic objects if this is a problem.
-
-Exceptions in catch handlers now go to outer block.
-
-@node Free Store, Concept Index, Exception Handling, Top
+The below points out some things that work in g++'s exception handling.
+
+All completely constructed temps and local variables are cleaned up in
+all unwinded scopes. Completely constructed parts of partially
+constructed objects are cleaned up. This includes partially built
+arrays. Exception specifications are now handled. Thrown objects are
+now cleaned up all the time. We can now tell if we have an active
+exception being thrown or not (__eh_type != 0). We use this to call
+terminate if someone does a throw; without there being an active
+exception object. uncaught_exception () works. Exception handling
+should work right if you optimize. Exception handling should work with
+-fpic or -fPIC.
+
+The below points out some flaws in g++'s exception handling, as it now
+stands.
+
+Only exact type matching or reference matching of throw types works when
+-fno-rtti is used. Only works on a SPARC (like Suns) (both -mflat and
+-mno-flat models work), SPARClite, Hitachi SH, i386, arm, rs6000,
+PowerPC, Alpha, mips, VAX, m68k and z8k machines. SPARC v9 may not
+work. HPPA is mostly done, but throwing between a shared library and
+user code doesn't yet work. Some targets have support for data-driven
+unwinding. Partial support is in for all other machines, but a stack
+unwinder called __unwind_function has to be written, and added to
+libgcc2 for them. The new EH code doesn't rely upon the
+__unwind_function for C++ code, instead it creates per function
+unwinders right inside the function, unfortunately, on many platforms
+the definition of RETURN_ADDR_RTX in the tm.h file for the machine port
+is wrong. See below for details on __unwind_function. RTL_EXPRs for EH
+cond variables for && and || exprs should probably be wrapped in
+UNSAVE_EXPRs, and RTL_EXPRs tweaked so that they can be unsaved.
+
+We only do pointer conversions on exception matching a la 15.3 p2 case
+3: `A handler with type T, const T, T&, or const T& is a match for a
+throw-expression with an object of type E if [3]T is a pointer type and
+E is a pointer type that can be converted to T by a standard pointer
+conversion (_conv.ptr_) not involving conversions to pointers to private
+or protected base classes.' when -frtti is given.
+
+We don't call delete on new expressions that die because the ctor threw
+an exception. See except/18 for a test case.
+
+15.2 para 13: The exception being handled should be rethrown if control
+reaches the end of a handler of the function-try-block of a constructor
+or destructor, right now, it is not.
+
+15.2 para 12: If a return statement appears in a handler of
+function-try-block of a constructor, the program is ill-formed, but this
+isn't diagnosed.
+
+15.2 para 11: If the handlers of a function-try-block contain a jump
+into the body of a constructor or destructor, the program is ill-formed,
+but this isn't diagnosed.
+
+15.2 para 9: Check that the fully constructed base classes and members
+of an object are destroyed before entering the handler of a
+function-try-block of a constructor or destructor for that object.
+
+build_exception_variant should sort the incoming list, so that it
+implements set compares, not exact list equality. Type smashing should
+smash exception specifications using set union.
+
+Thrown objects are usually allocated on the heap, in the usual way. If
+one runs out of heap space, throwing an object will probably never work.
+This could be relaxed some by passing an __in_chrg parameter to track
+who has control over the exception object. Thrown objects are not
+allocated on the heap when they are pointer to object types. We should
+extend it so that all small (<4*sizeof(void*)) objects are stored
+directly, instead of allocated on the heap.
+
+When the backend returns a value, it can create new exception regions
+that need protecting. The new region should rethrow the object in
+context of the last associated cleanup that ran to completion.
+
+The structure of the code that is generated for C++ exception handling
+code is shown below:
+
+@example
+Ln: throw value;
+ copy value onto heap
+ jump throw (Ln, id, address of copy of value on heap)
+
+ try @{
++Lstart: the start of the main EH region
+|... ...
++Lend: the end of the main EH region
+ @} catch (T o) @{
+ ...1
+ @}
+Lresume:
+ nop used to make sure there is something before
+ the next region ends, if there is one
+... ...
+
+ jump Ldone
+[
+Lmainhandler: handler for the region Lstart-Lend
+ cleanup
+] zero or more, depending upon automatic vars with dtors
++Lpartial:
+| jump Lover
++Lhere:
+ rethrow (Lhere, same id, same obj);
+Lterm: handler for the region Lpartial-Lhere
+ call terminate
+Lover:
+[
+ [
+ call throw_type_match
+ if (eq) @{
+ ] these lines disappear when there is no catch condition
++Lsregion2:
+| ...1
+| jump Lresume
+|Lhandler: handler for the region Lsregion2-Leregion2
+| rethrow (Lresume, same id, same obj);
++Leregion2
+ @}
+] there are zero or more of these sections, depending upon how many
+ catch clauses there are
+----------------------------- expand_end_all_catch --------------------------
+ here we have fallen off the end of all catch
+ clauses, so we rethrow to outer
+ rethrow (Lresume, same id, same obj);
+----------------------------- expand_end_all_catch --------------------------
+[
+L1: maybe throw routine
+] depending upon if we have expanded it or not
+Ldone:
+ ret
+
+start_all_catch emits labels: Lresume,
+
+@end example
+
+The __unwind_function takes a pointer to the throw handler, and is
+expected to pop the stack frame that was built to call it, as well as
+the frame underneath and then jump to the throw handler. It must
+restore all registers to their proper values as well as all other
+machine state as determined by the context in which we are unwinding
+into. The way I normally start is to compile:
+
+ void *g;
+ foo(void* a) @{ g = a; @}
+
+with -S, and change the thing that alters the PC (return, or ret
+usually) to not alter the PC, making sure to leave all other semantics
+(like adjusting the stack pointer, or frame pointers) in. After that,
+replicate the prologue once more at the end, again, changing the PC
+altering instructions, and finally, at the very end, jump to `g'.
+
+It takes about a week to write this routine, if someone wants to
+volunteer to write this routine for any architecture, exception support
+for that architecture will be added to g++. Please send in those code
+donations. One other thing that needs to be done, is to double check
+that __builtin_return_address (0) works.
+
+@subsection Specific Targets
+
+For the alpha, the __unwind_function will be something resembling:
+
+@example
+void
+__unwind_function(void *ptr)
+@{
+ /* First frame */
+ asm ("ldq $15, 8($30)"); /* get the saved frame ptr; 15 is fp, 30 is sp */
+ asm ("bis $15, $15, $30"); /* reload sp with the fp we found */
+
+ /* Second frame */
+ asm ("ldq $15, 8($30)"); /* fp */
+ asm ("bis $15, $15, $30"); /* reload sp with the fp we found */
+
+ /* Return */
+ asm ("ret $31, ($16), 1"); /* return to PTR, stored in a0 */
+@}
+@end example
+
+@noindent
+However, there are a few problems preventing it from working. First of
+all, the gcc-internal function @code{__builtin_return_address} needs to
+work given an argument of 0 for the alpha. As it stands as of August
+30th, 1995, the code for @code{BUILT_IN_RETURN_ADDRESS} in @file{expr.c}
+will definitely not work on the alpha. Instead, we need to define
+the macros @code{DYNAMIC_CHAIN_ADDRESS} (maybe),
+@code{RETURN_ADDR_IN_PREVIOUS_FRAME}, and definitely need a new
+definition for @code{RETURN_ADDR_RTX}.
+
+In addition (and more importantly), we need a way to reliably find the
+frame pointer on the alpha. The use of the value 8 above to restore the
+frame pointer (register 15) is incorrect. On many systems, the frame
+pointer is consistently offset to a specific point on the stack. On the
+alpha, however, the frame pointer is pushed last. First the return
+address is stored, then any other registers are saved (e.g., @code{s0}),
+and finally the frame pointer is put in place. So @code{fp} could have
+an offset of 8, but if the calling function saved any registers at all,
+they add to the offset.
+
+The only places the frame size is noted are with the @samp{.frame}
+directive, for use by the debugger and the OSF exception handling model
+(useless to us), and in the initial computation of the new value for
+@code{sp}, the stack pointer. For example, the function may start with:
+
+@example
+lda $30,-32($30)
+.frame $15,32,$26,0
+@end example
+
+@noindent
+The 32 above is exactly the value we need. With this, we can be sure
+that the frame pointer is stored 8 bytes less---in this case, at 24(sp)).
+The drawback is that there is no way that I (Brendan) have found to let
+us discover the size of a previous frame @emph{inside} the definition
+of @code{__unwind_function}.
+
+So to accomplish exception handling support on the alpha, we need two
+things: first, a way to figure out where the frame pointer was stored,
+and second, a functional @code{__builtin_return_address} implementation
+for except.c to be able to use it.
+
+Or just support DWARF 2 unwind info.
+
+@subsection New Backend Exception Support
+
+This subsection discusses various aspects of the design of the
+data-driven model being implemented for the exception handling backend.
+
+The goal is to generate enough data during the compilation of user code,
+such that we can dynamically unwind through functions at run time with a
+single routine (@code{__throw}) that lives in libgcc.a, built by the
+compiler, and dispatch into associated exception handlers.
+
+This information is generated by the DWARF 2 debugging backend, and
+includes all of the information __throw needs to unwind an arbitrary
+frame. It specifies where all of the saved registers and the return
+address can be found at any point in the function.
+
+Major disadvantages when enabling exceptions are:
+
+@itemize @bullet
+@item
+Code that uses caller saved registers, can't, when flow can be
+transferred into that code from an exception handler. In high performance
+code this should not usually be true, so the effects should be minimal.
+
+@end itemize
+
+@subsection Backend Exception Support
+
+The backend must be extended to fully support exceptions. Right now
+there are a few hooks into the alpha exception handling backend that
+resides in the C++ frontend from that backend that allows exception
+handling to work in g++. An exception region is a segment of generated
+code that has a handler associated with it. The exception regions are
+denoted in the generated code as address ranges denoted by a starting PC
+value and an ending PC value of the region. Some of the limitations
+with this scheme are:
+
+@itemize @bullet
+@item
+The backend replicates insns for such things as loop unrolling and
+function inlining. Right now, there are no hooks into the frontend's
+exception handling backend to handle the replication of insns. When
+replication happens, a new exception region descriptor needs to be
+generated for the new region.
+
+@item
+The backend expects to be able to rearrange code, for things like jump
+optimization. Any rearranging of the code needs have exception region
+descriptors updated appropriately.
+
+@item
+The backend can eliminate dead code. Any associated exception region
+descriptor that refers to fully contained code that has been eliminated
+should also be removed, although not doing this is harmless in terms of
+semantics.
+
+@end itemize
+
+The above is not meant to be exhaustive, but does include all things I
+have thought of so far. I am sure other limitations exist.
+
+Below are some notes on the migration of the exception handling code
+backend from the C++ frontend to the backend.
+
+NOTEs are to be used to denote the start of an exception region, and the
+end of the region. I presume that the interface used to generate these
+notes in the backend would be two functions, start_exception_region and
+end_exception_region (or something like that). The frontends are
+required to call them in pairs. When marking the end of a region, an
+argument can be passed to indicate the handler for the marked region.
+This can be passed in many ways, currently a tree is used. Another
+possibility would be insns for the handler, or a label that denotes a
+handler. I have a feeling insns might be the best way to pass it.
+Semantics are, if an exception is thrown inside the region, control is
+transferred unconditionally to the handler. If control passes through
+the handler, then the backend is to rethrow the exception, in the
+context of the end of the original region. The handler is protected by
+the conventional mechanisms; it is the frontend's responsibility to
+protect the handler, if special semantics are required.
+
+This is a very low level view, and it would be nice is the backend
+supported a somewhat higher level view in addition to this view. This
+higher level could include source line number, name of the source file,
+name of the language that threw the exception and possibly the name of
+the exception. Kenner may want to rope you into doing more than just
+the basics required by C++. You will have to resolve this. He may want
+you to do support for non-local gotos, first scan for exception handler,
+if none is found, allow the debugger to be entered, without any cleanups
+being done. To do this, the backend would have to know the difference
+between a cleanup-rethrower, and a real handler, if would also have to
+have a way to know if a handler `matches' a thrown exception, and this
+is frontend specific.
+
+The stack unwinder is one of the hardest parts to do. It is highly
+machine dependent. The form that kenner seems to like was a couple of
+macros, that would do the machine dependent grunt work. One preexisting
+function that might be of some use is __builtin_return_address (). One
+macro he seemed to want was __builtin_return_address, and the other
+would do the hard work of fixing up the registers, adjusting the stack
+pointer, frame pointer, arg pointer and so on.
+
+
+@node Free Store, Mangling, Exception Handling, Top
@section Free Store
-operator new [] adds a magic cookie to the beginning of arrays for which
-the number of elements will be needed by operator delete []. These are
-arrays of objects with destructors and arrays of objects that define
-operator delete [] with the optional size_t argument. This cookie can
-be examined from a program as follows:
+@code{operator new []} adds a magic cookie to the beginning of arrays
+for which the number of elements will be needed by @code{operator delete
+[]}. These are arrays of objects with destructors and arrays of objects
+that define @code{operator delete []} with the optional size_t argument.
+This cookie can be examined from a program as follows:
@example
typedef unsigned long size_t;
@}
@end example
-@node Concept Index, , Free Store, Top
+@section Linkage
+The linkage code in g++ is horribly twisted in order to meet two design goals:
+
+1) Avoid unnecessary emission of inlines and vtables.
+
+2) Support pedantic assemblers like the one in AIX.
+
+To meet the first goal, we defer emission of inlines and vtables until
+the end of the translation unit, where we can decide whether or not they
+are needed, and how to emit them if they are.
+
+@node Mangling, Concept Index, Free Store, Top
+@section Function name mangling for C++ and Java
+
+Both C++ and Jave provide overloaded function and methods,
+which are methods with the same types but different parameter lists.
+Selecting the correct version is done at compile time.
+Though the overloaded functions have the same name in the source code,
+they need to be translated into different assembler-level names,
+since typical assemblers and linkers cannot handle overloading.
+This process of encoding the parameter types with the method name
+into a unique name is called @dfn{name mangling}. The inverse
+process is called @dfn{demangling}.
+
+It is convenient that C++ and Java use compatible mangling schemes,
+since the makes life easier for tools such as gdb, and it eases
+integration between C++ and Java.
+
+Note there is also a standard "Jave Native Interface" (JNI) which
+implements a different calling convention, and uses a different
+mangling scheme. The JNI is a rather abstract ABI so Java can call methods
+written in C or C++;
+we are concerned here about a lower-level interface primarily
+intended for methods written in Java, but that can also be used for C++
+(and less easily C).
+
+Note that on systems that follow BSD tradition, a C identifier @code{var}
+would get "mangled" into the assembler name @samp{_var}. On such
+systems, all other mangled names are also prefixed by a @samp{_}
+which is not shown in the following examples.
+
+@subsection Method name mangling
+
+C++ mangles a method by emitting the function name, followed by @code{__},
+followed by encodings of any method qualifiers (such as @code{const}),
+followed by the mangling of the method's class,
+followed by the mangling of the parameters, in order.
+
+For example @code{Foo::bar(int, long) const} is mangled
+as @samp{bar__C3Fooil}.
+
+For a constructor, the method name is left out.
+That is @code{Foo::Foo(int, long) const} is mangled
+as @samp{__C3Fooil}.
+
+GNU Java does the same.
+
+@subsection Primitive types
+
+The C++ types @code{int}, @code{long}, @code{short}, @code{char},
+and @code{long long} are mangled as @samp{i}, @samp{l},
+@samp{s}, @samp{c}, and @samp{x}, respectively.
+The corresponding unsigned types have @samp{U} prefixed
+to the mangling. The type @code{signed char} is mangled @samp{Sc}.
+
+The C++ and Java floating-point types @code{float} and @code{double}
+are mangled as @samp{f} and @samp{d} respectively.
+
+The C++ @code{bool} type and the Java @code{boolean} type are
+mangled as @samp{b}.
+
+The C++ @code{wchar_t} and the Java @code{char} types are
+mangled as @samp{w}.
+
+The Java integral types @code{byte}, @code{short}, @code{int}
+and @code{long} are mangled as @samp{c}, @samp{s}, @samp{i},
+and @samp{x}, respectively.
+
+C++ code that has included @code{javatypes.h} will mangle
+the typedefs @code{jbyte}, @code{jshort}, @code{jint}
+and @code{jlong} as respectively @samp{c}, @samp{s}, @samp{i},
+and @samp{x}. (This has not been implemented yet.)
+
+@subsection Mangling of simple names
+
+A simple class, package, template, or namespace name is
+encoded as the number of characters in the name, followed by
+the actual characters. Thus the class @code{Foo}
+is encoded as @samp{3Foo}.
+
+If any of the characters in the name are not alphanumeric
+(i.e not one of the standard ASCII letters, digits, or '_'),
+or the initial character is a digit, then the name is
+mangled as a sequence of encoded Unicode letters.
+A Unicode encoding starts with a @samp{U} to indicate
+that Unicode escapes are used, followed by the number of
+bytes used by the Unicode encoding, followed by the bytes
+representing the encoding. ASSCI letters and
+non-initial digits are encoded without change. However, all
+other characters (including underscore and initial digits) are
+translated into a sequence starting with an underscore,
+followed by the big-endian 4-hex-digit lower-case encoding of the character.
+
+If a method name contains Unicode-escaped characters, the
+entire mangled method name is followed by a @samp{U}.
+
+For example, the method @code{X\u0319::M\u002B(int)} is encoded as
+@samp{M_002b__U6X_0319iU}.
+
+
+@subsection Pointer and reference types
+
+A C++ pointer type is mangled as @samp{P} followed by the
+mangling of the type pointed to.
+
+A C++ reference type as mangled as @samp{R} followed by the
+mangling of the type referenced.
+
+A Java object reference type is equivalent
+to a C++ pointer parameter, so we mangle such an parameter type
+as @samp{P} followed by the mangling of the class name.
+
+@subsection Squangled type compression
+
+Squangling (enabled with the @samp{-fsquangle} option), utilizes the
+@samp{B} code to indicate reuse of a previously seen type within an
+indentifier. Types are recognized in a left to right manner and given
+increasing values, which are appended to the code in the standard
+manner. Ie, multiple digit numbers are delimited by @samp{_}
+characters. A type is considered to be any non primitive type,
+regardless of whether its a parameter, template parameter, or entire
+template. Certain codes are considered modifiers of a type, and are not
+included as part of the type. These are the @samp{C}, @samp{V},
+@samp{P}, @samp{A}, @samp{R}, @samp{U} and @samp{u} codes, denoting
+constant, volatile, pointer, array, reference, unsigned, and restrict.
+These codes may precede a @samp{B} type in order to make the required
+modifications to the type.
+
+For example:
+@example
+template <class T> class class1 @{ @};
+
+template <class T> class class2 @{ @};
+
+class class3 @{ @};
+
+int f(class2<class1<class3> > a ,int b, const class1<class3>&c, class3 *d) @{ @}
+
+ B0 -> class2<class1<class3>
+ B1 -> class1<class3>
+ B2 -> class3
+@end example
+Produces the mangled name @samp{f__FGt6class21Zt6class11Z6class3iRCB1PB2}.
+The int parameter is a basic type, and does not receive a B encoding...
+
+@subsection Qualified names
+
+Both C++ and Java allow a class to be lexically nested inside another
+class. C++ also supports namespaces.
+Java also supports packages.
+
+These are all mangled the same way: First the letter @samp{Q}
+indicates that we are emitting a qualified name.
+That is followed by the number of parts in the qualified name.
+If that number is 9 or less, it is emitted with no delimiters.
+Otherwise, an underscore is written before and after the count.
+Then follows each part of the qualified name, as described above.
+
+For example @code{Foo::\u0319::Bar} is encoded as
+@samp{Q33FooU5_03193Bar}.
+
+Squangling utilizes the the letter @samp{K} to indicate a
+remembered portion of a qualified name. As qualified names are processed
+for an identifier, the names are numbered and remembered in a
+manner similar to the @samp{B} type compression code.
+Names are recognized left to right, and given increasing values, which are
+appended to the code in the standard manner. ie, multiple digit numbers
+are delimited by @samp{_} characters.
+
+For example
+@example
+class Andrew
+@{
+ class WasHere
+ @{
+ class AndHereToo
+ @{
+ @};
+ @};
+@};
+
+f(Andrew&r1, Andrew::WasHere& r2, Andrew::WasHere::AndHereToo& r3) @{ @}
+
+ K0 -> Andrew
+ K1 -> Andrew::WasHere
+ K2 -> Andrew::WasHere::AndHereToo
+@end example
+Function @samp{f()} would be mangled as :
+@samp{f__FR6AndrewRQ2K07WasHereRQ2K110AndHereToo}
+
+There are some occasions when either a @samp{B} or @samp{K} code could
+be chosen, preference is always given to the @samp{B} code. Ie, the example
+in the section on @samp{B} mangling could have used a @samp{K} code
+instead of @samp{B2}.
+
+@subsection Templates
+
+A class template instantiation is encoded as the letter @samp{t},
+followed by the encoding of the template name, followed
+the number of template parameters, followed by encoding of the template
+parameters. If a template parameter is a type, it is written
+as a @samp{Z} followed by the encoding of the type.
+
+A function template specialization (either an instantiation or an
+explicit specialization) is encoded by an @samp{H} followed by the
+encoding of the template parameters, as described above, followed by an
+@samp{_}, the encoding of the argument types to the template function
+(not the specialization), another @samp{_}, and the return type. (Like
+the argument types, the return type is the return type of the function
+template, not the specialization.) Template parameters in the argument
+and return types are encoded by an @samp{X} for type parameters, or a
+@samp{Y} for constant parameters, an index indicating their position
+in the template parameter list declaration, and their template depth.
+
+@subsection Arrays
+
+C++ array types are mangled by emitting @samp{A}, followed by
+the length of the array, followed by an @samp{_}, followed by
+the mangling of the element type. Of course, normally
+array parameter types decay into a pointer types, so you
+don't see this.
+
+Java arrays are objects. A Java type @code{T[]} is mangled
+as if it were the C++ type @code{JArray<T>}.
+For example @code{java.lang.String[]} is encoded as
+@samp{Pt6JArray1ZPQ34java4lang6String}.
+
+@subsection Static fields
+
+Both C++ and Java classes can have static fields.
+These are allocated statically, and are shared among all instances.
+
+The mangling starts with a prefix (@samp{_} in most systems), which is
+followed by the mangling
+of the class name, followed by the "joiner" and finally the field name.
+The joiner (see @code{JOINER} in @code{cp-tree.h}) is a special
+separator character. For historical reasons (and idiosyncracies
+of assembler syntax) it can @samp{$} or @samp{.} (or even
+@samp{_} on a few systems). If the joiner is @samp{_} then the prefix
+is @samp{__static_} instead of just @samp{_}.
+
+For example @code{Foo::Bar::var} (or @code{Foo.Bar.var} in Java syntax)
+would be encoded as @samp{_Q23Foo3Bar$var} or @samp{_Q23Foo3Bar.var}
+(or rarely @samp{__static_Q23Foo3Bar_var}).
+
+If the name of a static variable needs Unicode escapes,
+the Unicode indicator @samp{U} comes before the "joiner".
+This @code{\u1234Foo::var\u3445} becomes @code{_U8_1234FooU.var_3445}.
+
+@subsection Table of demangling code characters
+
+The following special characters are used in mangling:
+
+@table @samp
+@item A
+Indicates a C++ array type.
+
+@item b
+Encodes the C++ @code{bool} type,
+and the Java @code{boolean} type.
+
+@item B
+Used for squangling. Similar in concept to the 'T' non-squangled code.
+
+@item c
+Encodes the C++ @code{char} type, and the Java @code{byte} type.
+
+@item C
+A modifier to indicate a @code{const} type.
+Also used to indicate a @code{const} member function
+(in which cases it precedes the encoding of the method's class).
+
+@item d
+Encodes the C++ and Java @code{double} types.
+
+@item e
+Indicates extra unknown arguments @code{...}.
+
+@item E
+Indicates the opening parenthesis of an expression.
+
+@item f
+Encodes the C++ and Java @code{float} types.
+
+@item F
+Used to indicate a function type.
+
+@item H
+Used to indicate a template function.
+
+@item i
+Encodes the C++ and Java @code{int} types.
+
+@item I
+Encodes typedef names of the form @code{int@var{n}_t}, where @var{n} is a
+positive decimal number. The @samp{I} is followed by either two
+hexidecimal digits, which encode the value of @var{n}, or by an
+arbitrary number of hexidecimal digits between underscores. For
+example, @samp{I40} encodes the type @code{int64_t}, and @samp{I_200_}
+encodes the type @code{int512_t}.
+
+@item J
+Indicates a complex type.
+
+@item K
+Used by squangling to compress qualified names.
+
+@item l
+Encodes the C++ @code{long} type.
+
+@item n
+Immediate repeated type. Followed by the repeat count.
+
+@item N
+Repeated type. Followed by the repeat count of the repeated type,
+followed by the type index of the repeated type. Due to a bug in
+g++ 2.7.2, this is only generated if index is 0. Superceded by
+@samp{n} when squangling.
+
+@item P
+Indicates a pointer type. Followed by the type pointed to.
+
+@item Q
+Used to mangle qualified names, which arise from nested classes.
+Also used for namespaces.
+In Java used to mangle package-qualified names, and inner classes.
+
+@item r
+Encodes the GNU C++ @code{long double} type.
+
+@item R
+Indicates a reference type. Followed by the referenced type.
+
+@item s
+Encodes the C++ and java @code{short} types.
+
+@item S
+A modifier that indicates that the following integer type is signed.
+Only used with @code{char}.
+
+Also used as a modifier to indicate a static member function.
+
+@item t
+Indicates a template instantiation.
+
+@item T
+A back reference to a previously seen type.
+
+@item U
+A modifier that indicates that the following integer type is unsigned.
+Also used to indicate that the following class or namespace name
+is encoded using Unicode-mangling.
+
+@item u
+The @code{restrict} type qualifier.
+
+@item v
+Encodes the C++ and Java @code{void} types.
+
+@item V
+A modifier for a @code{volatile} type or method.
+
+@item w
+Encodes the C++ @code{wchar_t} type, and the Java @code{char} types.
+
+@item W
+Indicates the closing parenthesis of an expression.
+
+@item x
+Encodes the GNU C++ @code{long long} type, and the Java @code{long} type.
+
+@item X
+Encodes a template type parameter, when part of a function type.
+
+@item Y
+Encodes a template constant parameter, when part of a function type.
+
+@item Z
+Used for template type parameters.
+
+@end table
+
+The letters @samp{G}, @samp{M}, @samp{O}, and @samp{p}
+also seem to be used for obscure purposes ...
+
+@node Concept Index, , Mangling, Top
+
@section Concept Index
@printindex cp
OSDN Git Service
