Understanding the C ABI

C ABI is the underlying rules that the compiler follows when generating binary code, which determines mechanisms such as function calls, object layout, name adaptation and other mechanisms; 1. It ensures that different compilation units interact correctly, 2. Different compilers or versions may adopt different ABIs, affecting dynamic library links, STL transfers, virtual function calls, etc. 3. Cross-platform development, long-term system maintenance, third-party library use and other scenarios need to pay special attention to ABI consistency, 4. The ABI can be controlled through macro definitions and compilation options, and use tools to view the symbol table to judge consistency.

C ABI (Application Binary Interface) is a set of rules that the compiler follows when generating binary code, which determines the function call method, object layout, name mangling, exception handling mechanism, etc. Understanding it is very critical for those who develop high-performance or cross-platform projects, especially when doing dynamic library compatibility, system-level debugging, or compiler development.

What is C ABI?

Simply put, ABI is a set of underlying specifications that ensure that different compilation units can interact correctly. For example, if you write a class, use its objects in another file, or call a function in a dynamic link library, the ABI is coordinating these details. If the ABI used by the two modules is inconsistent, there may be problems such as crashes, call errors or even unlinkable.

Unlike API (application program interface), ABI is more underlying, focusing on how compiled machine code works. For example:

• How to pass function parameters (register or stack)
• The order of the class member variables
• Structure of virtual function table
• How to spread an exception
• Name adaptation format

These are not what programmers face directly, but they have a huge impact in some scenarios.

Why does C ABI affect compatibility?

The C language itself does not specify the specific implementation of ABI, which means that different compilers (such as GCC, Clang, MSVC) and even different versions of the same compiler may adopt different ABI rules. This difference can lead to the following problems:

• Dynamic library and main program cannot be linked normally
• STL containers behave abnormally when passing boundary (for example, std::string is different in size in two modules)
• Virtual function call jumps to the wrong position

For example: GCC uses C 11 ABI by default since 4.7, but in order to maintain compatibility, a macro _GLIBCXX_USE_CXX11_ABI is provided to switch back to the old version. If you compile one module with the new ABI and the other module with the old one, then the internal structure of types like std::string will be inconsistent, and the result will be various unpredictable bugs.

In what circumstances do you need to pay special attention to ABI?

For most application developers, ABI is something that is "invisible but must exist". But in the following typical scenarios, you have to pay attention to it:

• Develop cross-platform libraries : The compiler ABI on Windows and Linux is completely different. To ensure the stability of the library's interface, you need to design the abstraction layer.
• Maintain a long-running system : If the system components are composed of modules built at different points in time, ABI changes may lead to subsequent upgrade failures.
• Use third-party dynamic libraries : especially closed source libraries, you must confirm that their build environment matches your project.
• Embedded development : Cross-compilation is prone to inconsistent ABI due to different toolchain versions.

Common practices when encountering these problems include:

• Clearly specify compiler and version requirements
• Use stable intermediate interfaces (such as C-style API)
• Avoid exposing STL types as public interfaces
• Control the ABI switch (as mentioned above _GLIBCXX_USE_CXX11_ABI )

How to view or control C ABI?

Different compilers have different ways to view and set up ABIs. Taking GCC as an example, you can determine which ABI is currently using through macro definitions:

 #if defined(_GLIBCXX_USE_CXX11_ABI)
// Use the new version of ABI
#else
// Use old version of ABI
#endif

The way to control the ABI is also usually defined by compilation options or macros. For example, using -D_GLIBCXX_USE_CXX11_ABI=0 in newer GCC can force switch back to the old version of ABI.

In addition, you can also use nm or objdump tools to view the symbol table and observe the name adaptation format to determine whether the ABI is consistent.

Basically that's it. Although ABI is not something you touch every day, it can easily become a hidden pit in specific scenarios. Understand and pay attention in advance, which can save a lot of time for post-scheduling.

The above is the detailed content of Understanding the C ABI. For more information, please follow other related articles on the PHP Chinese website!