Application binary interface

An ABI defines the binary contract that compiled code must obey at an interface. Unlike an application programming interface (API), which describes source-level functions and types, an ABI specifies their machine-level realization: symbol names, calling sequences, register use, stack layout, alignment, data sizes, and return-value rules. The Executable and Linkable Format (ELF) specification, for example, defines object-file structures and relocation information used by linkers and loaders.¹

ABIs operate at several boundaries. A library ABI connects object files and shared libraries; a platform ABI connects programs to an operating system; and a processor ABI defines conventions for a particular instruction-set architecture. Compatibility therefore depends on the whole relevant environment, including architecture, operating system, compiler choices, linker conventions, and sometimes language runtime rules.

The calling convention determines how a function receives arguments and returns results. It assigns particular arguments to registers or stack locations, defines which registers a callee must preserve, specifies stack alignment, and describes treatment of structures, floating-point values, and variadic arguments. Microsoft’s x64 convention, for instance, reserves register and stack areas with rules that differ from common Unix conventions.⁴

An ABI also fixes data representation: integer widths, byte order, padding, alignment, pointer size, and layout of records or classes. C++ adds name mangling, virtual-function tables, object lifetime conventions, and exception-handling metadata; the Itanium C++ ABI documents these mechanisms for a widely adopted family of Unix-like toolchains.³ Linkers and dynamic loaders use symbol tables and relocation records to connect references with definitions, often leaving addresses to be finalized when a shared object is loaded.¹

Binary compatibility allows an existing executable to use a newer library without recompilation, but only when the ABI contract remains compatible. Changing a public structure’s field order, a function’s calling convention, symbol decoration, exception model, or ownership assumptions can break that contract even when source declarations look similar. An ABI may therefore evolve through versioned symbols, new entry points, reserved fields, and compatibility shims rather than by altering an existing interface.

Compiler and platform projects publish ABI rules to coordinate independently produced binaries. The ARM Architecture Procedure Call Standard and related documents cover procedure calls, data layout, and platform-specific conventions across ARM environments.² C is often used at stable binary boundaries because its object model is comparatively small; C++, Rust, and other languages can interoperate, but usually require an explicitly defined foreign-function interface and careful control of layout, unwinding, and allocation.

ABIs cover more than ordinary function calls. A system-call ABI specifies how user programs request kernel services, while an executable ABI can include thread-local storage, process startup state, signal frames, dynamic linking, debugging information, and exception unwinding. These details explain why a program may compile successfully yet fail at load time or corrupt data when linked against an incompatible binary.

Architecture families often have multiple ABIs with different trade-offs. ARM distinguishes procedure-call variants for hardware floating-point registers and software floating-point compatibility, while platform ABIs may impose additional rules for position-independent code or interworking between instruction sets.² C++ exception propagation is another edge case: an object may cross a library boundary safely only when the participating runtimes agree on unwinding and type-information conventions.³ ABI testing commonly combines compiler-produced “caller” and “callee” programs, symbol inspection, and conformance suites rather than relying solely on source-level tests.

Calling convention

Rules for passing arguments, returning values, preserving registers, and managing the stack during a function call.

Name mangling

Encoding of source-level names and type information into linker-visible symbol names, especially in C++.

Relocation

A linker or loader adjustment that resolves an address or other location-dependent value in machine code or data.

Foreign-function interface

A mechanism and set of conventions allowing code written in one language to call code written in another.