Application binary interface (ABI)

As you may already know, every library or framework, regardless of the technologies or the programming language used, exposes a set of certain functionalities, which is known as its Application Programming Interface (API). If a library is supposed to be used by another code, then the consumer code should use the provided API. To be clear, nothing other than the API should be used in order to use a library because it is the public interface of the library and everything else is seen as a black box, hence cannot be used.

Now suppose after some time, the library's API undergoes some modifications. In order for the consumer code to continue using the newer versions of the library, the code must adapt itself to the new API; otherwise, it won't be able to use it anymore. The consumer code could stick to a certain version of the library (maybe an old one) and ignore the newer versions, but let's assume that there is a desire to upgrade to the latest version of the library.

To put it simply, an API is like a convention (or standard) accepted between two software components to serve or use each other. An ABI is pretty similar to API, but at a different level. While the API guarantees the compatibility of two software components to continue their functional cooperation, the ABI guarantees that two programs are compatible at the level of their machine-level instructions, together with their corresponding object files.

For instance, a program cannot use a dynamic or static library that has a different ABI. Perhaps worse than that, an executable file (which is, in fact, an object file) cannot be run on a system supporting a different ABI than the one that the executable file was built for. A number of vital and obvious system functionalities, such as dynamic linking, loading an executable, and function calling convention, should be done precisely according to an agreed upon ABI.

An ABI will typically cover the following things:

• The instruction set of the target architecture, which includes the processor instructions, memory layout, endianness, registers, and so on.
• Existing data types, their sizes, and the alignment policy.
• The function calling convention describes how functions should be called. For example, subjects like the structure of the stack frame and the pushing order of the arguments are part of it.
• Defining how system calls should be called in a Unix-like system.
• Used object file format, which we will explain in the following section, for having relocatable, executable, and shared object files.
• Regarding object files produced by a C++ compiler, the name mangling, virtual table layout, is part of the ABI.

The System V ABI is the most widely used ABI standard among Unix-like operating systems like Linux and the BSD systems. Executable and Linking Format (ELF) is the standard object file format used in the System V ABI.

In the following section, we will discuss the object file formats, particularly ELF.