ABI
/ˌeɪ.biːˈaɪ/ · Abbreviation · Development
Definitions
ABI, or Application Binary Interface, defines the low-level interface between two binary program modules, specifying how functions are called, how data is laid out in memory, and how system calls are made at the machine code level. While an API defines source-level compatibility, an ABI ensures that compiled binaries can work together without recompilation. It covers calling conventions (how arguments are passed via registers or the stack), data type sizes and alignment, name mangling schemes, and the system call mechanism. ABI stability is critical for operating systems and shared libraries, because breaking the ABI forces all dependent software to be recompiled. Linux maintains a stable kernel ABI for userspace, and C++ ABI compatibility is a persistent challenge across different compilers and versions. Understanding ABIs is essential for systems programming, FFI (Foreign Function Interface), and cross-language interoperability.
In plain English: The rules that let compiled programs talk to each other at the machine-code level, like an agreement on how to pass data back and forth.
Example: "Breaking ABI compatibility in a shared library means every downstream package needs a recompile."
Etymology
- 1960s
- Early operating systems establish binary-level calling conventions, the precursor to formal ABIs.
- 1980s
- The System V ABI is standardized for Unix, defining how compiled programs interact with the OS and each other.
- 1993
- The Executable and Linkable Format (ELF) specification codifies ABI conventions for Linux and other Unix-like systems.
- 2010s
- ABI stability becomes a key concern for library maintainers. C++ ABI issues drive long debates in standards committees.
Origin Story
The Invisible Contract Between Software and Hardware
ABI, short for Application Binary Interface, defines the low-level contract between compiled programs and the operating system or hardware they run on. While APIs define how source code modules interact, ABIs define how compiled binary code interacts at the machine level: calling conventions, register usage, data type sizes, system call numbers, and object file formats. The concept emerged in the 1980s as Unix systems proliferated across different hardware architectures. Different vendors produced incompatible Unix variants, and programs compiled on one system would crash on another even when both ran 'Unix.' The IEEE's POSIX standardization effort in the late 1980s tried to address this at the API level, but binary compatibility required ABI standards too. The System V ABI, developed by AT&T for their System V Release 4 Unix in 1989, became one of the most influential ABI specifications and still forms the basis of the Linux ABI today. ABIs rarely make headlines, but they are critically important. When Linus Torvalds famously declared that the Linux kernel must never break userspace, he was talking about ABI stability: compiled programs must continue to work across kernel upgrades without recompilation.
Context: Unix standardization efforts, 1980s
Fun fact: Linus Torvalds considers ABI stability so sacred that he once told a kernel developer, 'We do not break userspace,' calling it 'rule number one' of Linux kernel development.