@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 Mike Stump @code{<mrs@@cygnus.com>}.
@menu
* Limitations of g++::
* 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
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
-(@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:
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.
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. Also, -frtti can alter the
-binary layout of classes, so mixing -frtti code and -fno-rtti code can
-be dangerous. The exceptions to this, are code that doesn't catch or
-throw exceptions, catch (...), and code that just rethrows an exception.
+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
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.
+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.
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), i386, arm,
-rs6000, PowerPC, Alpha, mips and VAX machines. 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. The HPPA has a brain dead abi that prevents
-exception handling from just working. See below for details on
-__unwind_function. Don't expect exception handling to work right if you
-optimize, in fact the compiler will probably core dump. 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, and the
-UNSAVE_EXPR code should be in the backend, or alternatively, UNSAVE_EXPR
-should be ripped out and exactly one finalization allowed to be expanded
-by the backend. I talked with kenner about this, and we have to allow
-multiple expansions.
+-fno-rtti is used. Only works on a SPARC (like Suns), SPARClite, i386,
+arm, rs6000, PowerPC, Alpha, mips, VAX, m68k and z8k machines. 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. The HPPA has a brain dead
+abi that prevents exception handling from just working. See below for
+details on __unwind_function. Don't expect exception handling to work
+right if you optimize, in fact the compiler will probably core dump.
+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, and the UNSAVE_EXPR code should be in the backend, or
+alternatively, UNSAVE_EXPR should be ripped out and exactly one
+finalization allowed to be expanded by the backend. I talked with
+kenner about this, and we have to allow multiple expansions.
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
have a way to know if a handler `matches' a thrown exception, and this
is frontend specific.
-The UNSAVE_EXPR tree code has to be migrated to the backend. Exprs such
-as TARGET_EXPRs, WITH_CLEANUP_EXPRs, CALL_EXPRs and RTL_EXPRs have to be
-changed to support unsaving. This is meant to be a complete list.
-SAVE_EXPRs can be unsaved already. expand_decl_cleanup should be
-changed to unsave it's argument, if needed. See
-cp/tree.c:cp_expand_decl_cleanup, unsave_expr_now, unsave_expr, and
-cp/expr.c:cplus_expand_expr(case UNSAVE_EXPR:) for the UNSAVE_EXPR code.
-Now, as to why... because kenner already tripped over the exact same
-problem in Ada, we talked about it, he didn't like any of the solution,
-but yet, didn't like no solution either. He was willing to live with
-the drawbacks of this solution. The drawback is unsave_expr_now. It
-should have a callback into the frontend, to allow the unsaveing of
-frontend special codes. The callback goes in, inplace of the call to
-my_friendly_abort.
-
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
would do the hard work of fixing up the registers, adjusting the stack
pointer, frame pointer, arg pointer and so on.
-The eh archive (~mrs/eh) might be good reading for understanding the Ada
-perspective, and some of kenners mindset, and a detailed explanation
-(Message-Id: <9308301130.AA10543@@vlsi1.ultra.nyu.edu>) of the concepts
-involved.
-
-Here is a guide to existing backend type code. It is all in
-cp/except.c. Check out do_unwind, and expand_builtin_throw for current
-code on how to figure out what handler matches an exception,
-emit_exception_table for code on emitting the PC range table that is
-built during compilation, expand_exception_blocks for code that emits
-all the handlers at the end of a functions, end_protect to mark the end
-of an exception region, start_protect to mark the start of an exception
-region, lang_interim_eh is the master hook used by the backend into the
-EH backend that now exists in the frontend, and expand_internal_throw to
-raise an exception.
-
-@node Free Store, Concept Index, Exception Handling, Top
+@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;
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).
+
+@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 Qualified names
+
+Both C++ and Java allow a class to be lexically nested inside another
+class. C++ also supports namespaces (not yet implemented by G++).
+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}.
+
+@subsection Templates
+
+A 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.
+
+@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 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 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 f
+Encodes the C++ and Java @code{float} types.
+
+@item F
+Used to indicate a function type.
+
+@item i
+Encodes the C++ and Java @code{int} types.
+
+@item J
+Indicates a complex type.
+
+@item l
+Encodes the C++ @code{long} type.
+
+@item P
+Indicates a pointer type. Followed by the type pointed to.
+
+@item Q
+Used to mangle qualified names, which arise from nested classes.
+Should also be 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 v
+Encodes the C++ and Java @code{void} types.
+
+@item V
+A modified for a @code{const} type or method.
+
+@item w
+Encodes the C++ @code{wchar_t} type, and the Java @code{char} types.
+
+@item x
+Encodes the GNU C++ @code{long long} type, and the Java @code{long} 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
-@node Concept Index, , Free Store, Top
@section Concept Index
@printindex cp
OSDN Git Service
