diff --git a/src/libmach/gpcompare.texi b/src/libmach/gpcompare.texi
new file mode 100644
index 00000000..7b0d5731
--- /dev/null
+++ b/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:
diff --git a/src/libmach/gxxint_15.html b/src/libmach/gxxint_15.html
new file mode 100644
index 00000000..cdee7dda
--- /dev/null
+++ b/src/libmach/gxxint_15.html
@@ -0,0 +1,375 @@
+
+
+
+
+G++ internals - Mangling
+
+
+Go to the first, previous, next, last section, table of contents.
+
+
+
+
+
+
+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).
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+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.)
+
+
+
+
+
+
+
+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'.
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+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'.
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+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'.
+
+
+
+
+
+
+
+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.
+
+