Anapplication binary interface (ABI) is aninterface exposed bysoftware that is defined for in-processmachine code access. Often, the exposing software is alibrary, and the consumer is aprogram.
An ABI is at a relatively low level ofabstraction. Interface compatibility depends on the targethardware and thesoftware buildtoolchain. In contrast, anapplication programming interface (API) defines access insource code, which is a relatively high-level, hardware-independent, andhuman-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 forsystem design and of the toolchain. However, aprogrammer may have to deal with an ABI directly when writing a program in multiplelanguages or when using multiplecompilers 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:
ABIs include theIntel Binary Compatibility Standard (iBCS)[3] and theSystem V Release 4 ABIs for various instruction sets.
Anembedded ABI (EABI), used on anembedded operating system, specifies aspects such asfile formats, data types, register usage,stack frame organization, and function parameter passing of anembedded software program.
Each compiler andassembler that supports an EABI createsobject 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 betweenkernel and user space typically found indesktop 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.[4] The choice of EABI can affect performance.[5][6]
Widely used EABIs include thePowerPC,[4]Arm,[7] andMIPS EABIs.[8] 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.[9]
Strictly speaking, both the old and new ARM ABIs are subsets of the ARM EABI specification, but in everyday usage the term "EABI" is used to mean the new one described here and "OABI" or "old-ABI" to mean the old one.
