commit c8661ffad4c2bbf1dd9138c4e8de7d86396cd070 from: rsc date: Tue Nov 29 04:05:50 2005 UTC demangling docs commit - 140c21e2f1fee2016af107b87f42a591f300f56a commit + c8661ffad4c2bbf1dd9138c4e8de7d86396cd070 blob - /dev/null blob + 7b0d573105b608f5db358b427fbcabe40f800dc5 (mode 644) --- /dev/null +++ src/libmach/gpcompare.texi @@ -0,0 +1,236 @@ +@node ANSI +@chapter @sc{gnu} C++ Conformance to @sc{ansi} C++ + +These changes in the @sc{gnu} C++ compiler were made to comply more +closely with the @sc{ansi} base document, @cite{The Annotated C++ +Reference Manual} (the @sc{arm}). Further reducing the divergences from +@sc{ansi} C++ is a continued goal of the @sc{gnu} C++ Renovation +Project. + +@b{Section 3.4}, @i{Start and Termination}. It is now invalid to take +the address of the function @samp{main()}. + +@b{Section 4.8}, @i{Pointers to Members}. The compiler produces +an error for trying to convert between a pointer to a member and the type +@samp{void *}. + +@b{Section 5.2.5}, @i{Increment and Decrement}. It is an error to use +the increment and decrement operators on an enumerated type. + +@b{Section 5.3.2}, @i{Sizeof}. Doing @code{sizeof} on a function is now +an error. + +@b{Section 5.3.4}, @i{Delete}. The syntax of a @i{cast-expression} is +now more strictly controlled. + +@b{Section 7.1.1}, @i{Storage Class Specifiers}. Using the +@code{static} and @code{extern} specifiers can now only be applied to +names of objects, functions, and anonymous unions. + +@b{Section 7.1.1}, @i{Storage Class Specifiers}. The compiler no longer complains +about taking the address of a variable which has been declared to have @code{register} +storage. + +@b{Section 7.1.2}, @i{Function Specifiers}. The compiler produces an +error when the @code{inline} or @code{virtual} specifiers are +used on anything other than a function. + +@b{Section 8.3}, @i{Function Definitions}. It is now an error to shadow +a parameter name with a local variable; in the past, the compiler only +gave a warning in such a situation. + +@b{Section 8.4.1}, @i{Aggregates}. The rules concerning declaration of +an aggregate are now all checked in the @sc{gnu} C++ compiler; they +include having no private or protected members and no base classes. + +@b{Section 8.4.3}, @i{References}. Declaring an array of references is +now forbidden. Initializing a reference with an initializer list is +also considered an error. + +@b{Section 9.5}, @i{Unions}. Global anonymous unions must be declared +@code{static}. + +@b{Section 11.4}, @i{Friends}. Declaring a member to be a friend of a +type that has not yet been defined is an error. + +@b{Section 12.1}, @i{Constructors}. The compiler generates a +default copy constructor for a class if no constructor has been declared. + +@ignore +@b{Section 12.4}, @i{Destructors}. In accordance with the @sc{ansi} C++ +draft standard working paper, a pure virtual destructor must now be +defined. +@end ignore + +@b{Section 12.6.2}, @i{Special Member Functions}. When using a +@i{mem-initializer} list, the compiler will now initialize class members +in declaration order, not in the order in which you specify them. +Also, the compiler enforces the rule that non-static @code{const} +and reference members must be initialized with a @i{mem-initializer} +list when their class does not have a constructor. + +@b{Section 12.8}, @i{Copying Class Objects}. The compiler generates +default copy constructors correctly, and supplies default assignment +operators compatible with user-defined ones. + +@b{Section 13.4}, @i{Overloaded Operators}. An overloaded operator may +no longer have default arguments. + +@b{Section 13.4.4}, @i{Function Call}. An overloaded @samp{operator ()} +must be a non-static member function. + +@b{Section 13.4.5}, @i{Subscripting}. An overloaded @samp{operator []} +must be a non-static member function. + +@b{Section 13.4.6}, @i{Class Member Access}. An overloaded @samp{operator ->} +must be a non-static member function. + +@b{Section 13.4.7}, @i{Increment and Decrement}. The compiler will now +make sure a postfix @samp{@w{operator ++}} or @samp{@w{operator --}} has an +@code{int} as its second argument. + + +@node Encoding +@chapter Name Encoding in @sc{gnu} C++ + +@c FIXME!! rewrite name encoding section +@c ...to give complete rules rather than diffs from ARM. +@c To avoid plagiarism, invent some different way of structuring the +@c description of the rules than what ARM uses. + +@cindex mangling +@cindex name encoding +@cindex encoding information in names +In order to support its strong typing rules and the ability to provide +function overloading, the C++ programming language @dfn{encodes} +information about functions and objects, so that conflicts across object +files can be detected during linking. @footnote{This encoding is also +sometimes called, whimsically enough, @dfn{mangling}; the corresponding +decoding is sometimes called @dfn{demangling}.} These rules tend to be +unique to each individual implementation of C++. + +The scheme detailed in the commentary for 7.2.1 of @cite{The Annotated +Reference Manual} offers a description of a possible implementation +which happens to closely resemble the @code{cfront} compiler. The +design used in @sc{gnu} C++ differs from this model in a number of ways: + +@itemize @bullet +@item +In addition to the basic types @code{void}, @code{char}, @code{short}, +@code{int}, @code{long}, @code{float}, @code{double}, and @code{long +double}, @sc{gnu} C++ supports two additional types: @code{wchar_t}, the wide +character type, and @code{long long} (if the host supports it). The +encodings for these are @samp{w} and @samp{x} respectively. + +@item +According to the @sc{arm}, qualified names (e.g., @samp{foo::bar::baz}) are +encoded with a leading @samp{Q}. Followed by the number of +qualifications (in this case, three) and the respective names, this +might be encoded as @samp{Q33foo3bar3baz}. @sc{gnu} C++ adds a leading +underscore to the list, producing @samp{_Q33foo3bar3baz}. + +@item +The operator @samp{*=} is encoded as @samp{__aml}, not @samp{__amu}, to +match the normal @samp{*} operator, which is encoded as @samp{__ml}. + +@c XXX left out ->(), __wr +@item +In addition to the normal operators, @sc{gnu} C++ also offers the minimum and +maximum operators @samp{>?} and @samp{ +@c To: mrs@@charlie.secs.csun.edu +@c Cc: g++@@cygnus.com +@c Subject: Re: ARM and GNU C++ incompatabilities +@c +@c Along with that, we should probably describe how g++ differs from +@c cfront, in ways that the users will notice. (E.g., cfront supposedly +@c allows "free (new char[10])"; does g++? How do the template +@c implementations differ? "New" placement syntax?) +@c @end display +@c +@c XXX For next revision. +@c +@c GNU C++: +@c * supports expanding inline functions in many situations, +@c including those which have static objects, use `for' statements, +@c and other situations. Part of this versatility is due to is +@c ability to not always generate temporaries for assignments. +@c * deliberately allows divide by 0 and mod 0, since [according +@c to Wilson] there are actually situations where you'd like to allow +@c such things. Note on most systems it will cause some sort of trap +@c or bus error. Cfront considers it an error. +@c * does [appear to] support nested classes within templates. +@c * conversion functions among baseclasses are all usable by +@c a class that's derived from all of those bases. +@c * sizeof works even when the class is defined within its ()'s +@c * conditional expressions work with member fns and pointers to +@c members. +@c * can handle non-trivial declarations of variables within switch +@c statements. +@c +@c Cfront: blob - /dev/null blob + cdee7dda202aa9ec3d3a57982d1419d6cfe0a1da (mode 644) --- /dev/null +++ src/libmach/gxxint_15.html @@ -0,0 +1,375 @@ + + + + +G++ internals - Mangling + + +Go to the first, previous, next, last section, table of contents. +

+ + +

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 name mangling. The inverse +process is called 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). + +

+ + +

Method name mangling

+ +

+C++ mangles a method by emitting the function name, followed by __, +followed by encodings of any method qualifiers (such as const), +followed by the mangling of the method's class, +followed by the mangling of the parameters, in order. + +

+

+For example Foo::bar(int, long) const is mangled +as `bar__C3Fooil'. + +

+

+For a constructor, the method name is left out. +That is Foo::Foo(int, long) const is mangled +as `__C3Fooil'. + +

+

+GNU Java does the same. + +

+ + +

Primitive types

+ +

+The C++ types int, long, short, char, +and long long are mangled as `i', `l', +`s', `c', and `x', respectively. +The corresponding unsigned types have `U' prefixed +to the mangling. The type signed char is mangled `Sc'. + +

+

+The C++ and Java floating-point types float and double +are mangled as `f' and `d' respectively. + +

+

+The C++ bool type and the Java boolean type are +mangled as `b'. + +

+

+The C++ wchar_t and the Java char types are +mangled as `w'. + +

+

+The Java integral types byte, short, int +and long are mangled as `c', `s', `i', +and `x', respectively. + +

+

+C++ code that has included javatypes.h will mangle +the typedefs jbyte, jshort, jint +and jlong as respectively `c', `s', `i', +and `x'. (This has not been implemented yet.) + +

+ + +

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 Foo +is encoded as `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 `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 `U'. + +

+

+For example, the method X\u0319::M\u002B(int) is encoded as +`M_002b__U6X_0319iU'. + +

+ + +

Pointer and reference types

+ +

+A C++ pointer type is mangled as `P' followed by the +mangling of the type pointed to. + +

+

+A C++ reference type as mangled as `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 `P' followed by the mangling of the class name. + +

+ + +

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 `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 Foo::\u0319::Bar is encoded as +`Q33FooU5_03193Bar'. + +

+ + +

Templates

+ +

+A class template instantiation is encoded as the letter `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 `Z' followed by the encoding of the type. + +

+

+A function template specialization (either an instantiation or an +explicit specialization) is encoded by an `H' followed by the +encoding of the template parameters, as described above, followed by +an `_', the encoding of the argument types template function (not the +specialization), another `_', 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 `X' for type parameters, or a +`Y' for constant parameters, and an index indicating their position +in the template parameter list declaration. + +

+ + +

Arrays

+ +

+C++ array types are mangled by emitting `A', followed by +the length of the array, followed by an `_', 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 T[] is mangled +as if it were the C++ type JArray<T>. +For example java.lang.String[] is encoded as +`Pt6JArray1ZPQ34java4lang6String'. + +

+ + +

Table of demangling code characters

+ +

+The following special characters are used in mangling: + +

+
+ +
`A' +
+Indicates a C++ array type. + +
`b' +
+Encodes the C++ bool type, +and the Java boolean type. + +
`c' +
+Encodes the C++ char type, and the Java byte type. + +
`C' +
+A modifier to indicate a const type. +Also used to indicate a const member function +(in which cases it precedes the encoding of the method's class). + +
`d' +
+Encodes the C++ and Java double types. + +
`e' +
+Indicates extra unknown arguments .... + +
`f' +
+Encodes the C++ and Java float types. + +
`F' +
+Used to indicate a function type. + +
`H' +
+Used to indicate a template function. + +
`i' +
+Encodes the C++ and Java int types. + +
`J' +
+Indicates a complex type. + +
`l' +
+Encodes the C++ long type. + +
`P' +
+Indicates a pointer type. Followed by the type pointed to. + +
`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. + +
`r' +
+Encodes the GNU C++ long double type. + +
`R' +
+Indicates a reference type. Followed by the referenced type. + +
`s' +
+Encodes the C++ and java short types. + +
`S' +
+A modifier that indicates that the following integer type is signed. +Only used with char. + +Also used as a modifier to indicate a static member function. + +
`t' +
+Indicates a template instantiation. + +
`T' +
+A back reference to a previously seen type. + +
`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. + +
`v' +
+Encodes the C++ and Java void types. + +
`V' +
+A modified for a const type or method. + +
`w' +
+Encodes the C++ wchar_t type, and the Java char types. + +
`x' +
+Encodes the GNU C++ long long type, and the Java long type. + +
`X' +
+Encodes a template type parameter, when part of a function type. + +
`Y' +
+Encodes a template constant parameter, when part of a function type. + +
`Z' +
+Used for template type parameters. + +
+ +

+The letters `G', `M', `O', and `p' +also seem to be used for obscure purposes ... + +

+

+Go to the first, previous, next, last section, table of contents. + +