C++ Name Mangling & ABI

The ABI: A Contract for Compilers

Before we dissect mangled names, it's essential to firmly grasp what an Application Binary Interface (ABI) is. While an API is a contract for a programmer (how to call a function in source code), an ABI is a contract for the compiler and linker (how to call a function in machine code). It defines the low-level, "under the hood" details.

To get a clear overview of the ABI and its importance, let's watch a few segments from a talk by Louis Dionne, a prominent C++ developer.

The ABI specifies many things, including:

• How function arguments are passed (in registers vs. on the stack).
• The memory layout of classes and structs.
• How virtual functions are called (which we'll cover later).
• And, crucially for this lesson, the scheme for name mangling.

Why C++ Needs a Mangling Scheme

As we saw in the previous lesson, C has a very simple ABI for function names: the symbol name is the same as the function name. This works because C does not allow two functions to have the same name in the same scope.

C++, on the other hand, supports features that require more information to be encoded into the symbol name:

• Function Overloading: foo(int) and foo(double) must have different symbol names.
• Namespaces: my_app::foo() and another_app::foo() must be distinguishable.
• Class Methods: A member function MyClass::foo() needs to be differentiated from a global foo().
• Templates: std::vector<int> and std::vector<double> are distinct types and their methods need unique symbols.

Name mangling is the solution. It's a set of rules for encoding this extra information into a string that the linker can use as a unique identifier.

Let's hear Louis Dionne explain this specific aspect.

Deconstructing a Mangled Name: The Itanium C++ ABI

While Microsoft's MSVC compiler has its own ABI, most non-Windows compilers, including GCC and Clang on Linux, have adopted the Itanium C++ ABI. Let's examine its mangling rules.

A great way to understand this is to read a detailed breakdown.

Now, let's put that theory into practice. Consider this function in a namespace:

namespace my_app {
    void print(int i, char c) { /* ... */ }
}

According to the Itanium ABI, the mangled name for this function would be _ZN6my_app5printEic. Let's break that down:

• _Z: The standard prefix for all mangled C++ symbols in the Itanium ABI.
• N: Indicates a nested name (i.e., inside a namespace or class).
• 6 my_app: The first part of the name is 6 characters long: "my_app".
• 5 print: The second part of the name is 5 characters long: "print".
• E: Marks the end of the nested name sequence.
• i: The first parameter is an int.
• c: The second parameter is a char.

As you can see, it's a deterministic encoding scheme. The linker doesn't see a function "print" in a namespace "my_app"; it just sees a unique global symbol named _ZN6my_app5printEic.

Tools of the Trade: nm, readelf, and c++filt

Understanding the theory is good, but seeing it in action is better. On Linux, you have powerful command-line tools to inspect symbols in your compiled object files and executables.

• nm: Lists symbols from object files.
• readelf -s: A more powerful tool that displays the full symbol table of an ELF file (object file, shared library, or executable).
• c++filt: A demangling tool. You give it a mangled name, and it gives you back the human-readable C++ signature.

Let's see how you'd use these. Imagine you have a file test.cpp with our my_app::print function.

1. Compile to an object file:

   g++ -c test.cpp -o test.o
   

2. Inspect the symbols:

   readelf -s test.o
   

   In the output, you would find a line containing our mangled name:
   ... FUNC GLOBAL DEFAULT ... _ZN6my_app5printEic

3. Demangle the name:

   c++filt _ZN6my_app5printEic
   

   This would output:
   my_app::print(int, char)

This workflow is incredibly valuable for debugging complex linker errors. It allows you to see exactly what symbols your compiler is generating and what symbols the linker is looking for.

The Impact on Linking: A Practical Demonstration

Now that we have a deep understanding of mangling, the problem of linking C and C++ code becomes crystal clear. A C compiler produces simple, unmangled symbols. A C++ compiler produces complex, mangled symbols. The linker, seeing two different names, cannot match them.

The extern "C" specifier is the explicit instruction to the C++ compiler to "switch to the C ABI" for a given function, meaning it should produce a simple, unmangled symbol.

This video provides a perfect, step-by-step demonstration of the entire issue.

The common pattern for making a C header file compatible with both C and C++ compilers uses the __cplusplus macro, which is only defined by C++ compilers.

namespace math_lib {
    class Calculator {
    public:
        double add(double a, double b);
    };
}

Conclusion

You have now dug deep into one of the most fundamental "under the hood" mechanisms that separates C++ from C. You've gone from knowing that name mangling exists to being able to analyze and even predict the structure of mangled names.

Key Takeaways:

• The Application Binary Interface (ABI) is a low-level contract that defines how compiled code interacts, including calling conventions and name mangling rules.
• C++'s name mangling is necessary to create unique linker symbols for features like function overloading and namespaces.
• The Itanium C++ ABI, used by GCC and Clang, has a specific encoding scheme (_Z, N...E, type codes) that deterministically converts a C++ signature into a unique symbol.
• Tools like readelf and c++filt allow you to inspect symbol tables and demangle names, which is invaluable for debugging linker issues.
• extern "C" works by instructing the C++ compiler to use the C ABI for a function, producing a simple, unmangled symbol that can be linked against C code.

In our next lesson, we will continue our comparative analysis of C and C++. We'll investigate references, a feature unique to C++, and analyze how they are typically implemented at the assembly level compared to their close relatives, pointers.