An application binary interface (ABI) is an interface exposed by software that is defined for in-process machine code access. Often, the exposing software is a library, and the consumer is a program.

An ABI is at a relatively low level of abstraction. Interface compatibility depends on the target hardware and the software build toolchain. In contrast, an application programming interface (API) defines access in source code, which is a relatively high-level, hardware-independent, and human-readable format. An API defines an interface at the source code level, before compilation, whereas an ABI defines an interface to compiled code.

API compatibility is generally the concern for system design and of the toolchain. However, a programmer may have to deal with an ABI directly when writing a program in multiple languages or when using multiple compilers for the same language.

A complete ABI enables a program that supports an ABI to run without modification on multiple operating systems that provide the ABI. The target system must provide any required libraries (that implement the ABI), and there may be other prerequisites.

Interface aspects covered by an ABI include:

• Processor instruction set, with details like register file structure, memory access types, etc.
• Size, layout, and alignment of basic data types that the processor can directly access
• Calling convention, which controls how the arguments of functions are passed, and return values retrieved; for example, it controls the following:
  • How the call stack is organized
  • Whether all parameters are passed on the call stack, or some are passed in registers
  • Which registers are used for which function parameters
  • Which registers should be preserved by the callee (restore its value if changed)
  • Whether the first function parameter passed on the call stack is pushed first or last
  • Whether the caller or callee is responsible for cleaning up the call stack after the function call
• Stack unwinding (setjmp/longjmp)
• Name mangling, or how an API entity is named in the resulting object file (not in C)^[1]
• Exception propagation (not in C)^[2]
• How an application should make system calls to the operating system, and if the ABI specifies direct system calls rather than procedure calls to system call stubs, the system call numbers
• In the case of a complete operating system ABI, the binary format of object files, program libraries, etc.

Example ABIs include the obsolete Intel Binary Compatibility Standard (iBCS),^[3], the System V Release 4 ABIs for various instruction set architectures (ISAs) used by many Unix-like systems, and the Microsoft Windows ABIs for various ISAs.^[4]

An embedded ABI (EABI), used on an embedded operating system, specifies aspects such as file formats, data types, register usage, stack frame organization, and function parameter passing of an embedded software program.

Each compiler and assembler that supports an EABI creates object code that is compatible with code generated by other such compilers and assemblers. This allows developers to link libraries generated by one compiler with object code generated by another.

Typically, an EABI is optimized for performance for the limited resources of the target embedded system. Therefore, an EABI may omit abstractions between kernel and user space typically found in desktop operating systems. For example, dynamic linking may be avoided to allow smaller executables and faster loading, fixed register usage allows more compact stacks and kernel calls, and running the application in privileged mode allows direct access to custom hardware operation without the indirection of calling a device driver.^[5] The choice of EABI can affect performance.^[6][7]

Widely used EABIs include the PowerPC,^[5] Arm,^[8] and MIPS EABIs.^[9] Specific software implementations like the C library may impose additional limitations to form more concrete ABIs; one example is the GNU OABI and EABI for ARM, both of which are subsets of the ARM EABI.^[10] Another point of distinction is whether optional features such as hardware floating-point is present. For example, in GCC and LLVM, armv7-unknown-linux-musleabi, armv7-unknown-linux-musleabihf both refer to GNU EABI with the musl C library, except the latter uses hardware floating-point and therefore has a slightly different call convention.^[11]

Each programming language may use a different set of features and data types. If there is no existing ABI for a feature, the language often needs to define its own ABI as an extension of the existing ABI.

The official website of the C programming language describes C as a lingua franca in foreign function interfaces (FFIs: function calls between different programming languages).^[12] Many languages define their FFIs around the C ABI, for example the extern "C" of Rust and C++.^[13] This is because almost every current operating system, both Unix-like and Windows, provides an agreed-upon C ABI. These systems themselves mainly provide a C API, which depends upon a C ABI for functioning, hence the ubiquity of a C ABI.^[14] (Furthermore, C is relatively limited in what it requires of the ABI rules compared to other languages, only requiring definition of data structure layout and calling convention.)^[15]

Nevertheless, C was not originally designed to serve in this role, and the ABI has been criticized for many of its perceived deficiencies as an FFI:

• C ABIs are defined by C APIs, which are defined in C header files. However, C header files are very hard to parse and most FFI implementations resort to calling the compiler.^[11]
• C ABIs define interpretations for C-specific types such as long long, time_t, intmax_t. These choices of types are set in stone by the ABI, but there exist valid reasons to change them, which ends up breaking the ABI.^[16]
• C ABIs do not have parts required to support features in other languages, e.g. type safety and memory safety.^[13]

There is no portable C++ ABI: even on the same operating system, different compilers (or combination of compiler and standard library implementations) may use different ABIs.^[13] Most C++ ABIs are extensions on top of the C ABI, filling in the missing name mangling (required for function overloading) and exception handling details. In modern systems two main schemes are encountered: Microsoft's Visual C++ scheme and the Itanium scheme.^[1]

Although the ABI documents define the rules for transforming identifiers into names, they do not define the whole ABI surface of the standard library, leaving it to the specific standard library implementation (see section "Library ABI" below). As a result, each implementation has its own ABI; even on the same architecture and operating system, two object files end up having different ABIs if linked to standard libraries with incompatible ABIs.^[13] In 2015, GCC/libstdc++ revised its implementation of std::string, leading to an ABI change. Even though the new library supports both ABIs, users still had to make a choice between the old ABI and the new ABI, as this determines what precompiled libraries their programs can be linked to.^[17] Similarly, Visual C++ does not guarantee compatibility when code produced by different versions of the compiler (intended for different versions of the runtime library) are linked together.^[18]

As defined above the "ABI" documents describe how an API is transformed into a concrete form at the assembly language level. In the case of libraries, the term "ABI" instead refers to the concrete interface resulting from the transformation of ABI.^[19] For example, changing the type signature of a function, either directly or indirectly (e.g. by changing the definition of a struct used by the function), often changes the ABI to the point of incompatibility, an "ABI break".^[20][21]

Because operating systems include a number of libraries for use by the programmer, their ABIs also include the library ABIs. The Linux Standard Base specifications, for example, includes details about what the symbol tables of certain libraries should contain, what API they correspond to, and that SysV ABI should be used.^[22] This kind of distinctions matter for compilers and other kinds of code generators; in the case of GCC and LLVM, each option is given a name called a target triple. (The choice of a standard library implementation also affects the ABI: for example, musl and uClibc for ARMv7 GNU EABI as well as libstdc++ and Microsoft Visual C++ for x64 Windows each have different triples.)^[11]

• Binary-code compatibility – Ability of computer system to run code for a different system
• Bytecode – Instruction set designed to be run by a software interpreter
• Comparison of application virtualization software
• Debug symbol – Information to facilitate code debuggingPages displaying short descriptions of redirect targets
• Foreign function interface – Interface to call functions from other programming languages
• Language binding – Interface allowing one programming language to use a library written in another
• Native (computing) – Software that operates directly in a given context
• Opaque pointer – Opaque data type which stores a memory address
• PowerOpen Environment – Open standard by AIM alliance
• Symbol table – Data structure used by a language translator such as a compiler or interpreter
• SWIG – Open-source programming tool
• Microsoft Visual C++ – Integrated development environment product

• Policies/Binary Compatibility Issues With C++ – a compendium of development rules of thumb for not breaking binary compatibility between library releases
• OS X ABI Function Call Guide
• Debian ARM EABI port
• μClib: Motorola 8/16-bit embedded ABI
• AMD64 (x86-64) Application Binary Interface at the Wayback Machine (archived 2008-05-28)
• Application Binary Interface (ABI) for the ARM Architecture
• MIPS EABI documentation
• Sun Studio 10 Compilers and the AMD64 ABI at the Wayback Machine (archived 2015-01-14) – a summary and comparison of some popular ABIs
• M•CORE Applications Binary Interface Standards Manual for the Freescale M·CORE processors