Application binary interface

Description

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
  • 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
• Name mangling
• Exception propagation
• 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.

ABIs include the Intel Binary Compatibility Standard (iBCS) and the System V Release 4 ABIs for various instruction sets.

{{Anchor|EABI}}Embedded ABI

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.{{cite book |access-date=11 October 2007 |archive-url=https://web.archive.org/web/20070121183413/http://www.linuxdevices.com/news/NS9048137234.html |archive-date=21 January 2007 |url-status=dead |access-date=11 October 2007 |archive-url=https://web.archive.org/web/20070331193917/http://www.linuxdevices.com/articles/AT5920399313.html |archive-date=31 March 2007 |url-status=dead

Widely used EABIs include the PowerPC, Arm, and MIPS EABIs. 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.

References

References

1. "Itanium C++ ABI".
2. "Itanium C++ ABI: Exception Handling".
3. "Intel Binary Compatibility Standard (iBCS)".
4. "ABI for the Arm Architecture". Developer.arm.com.
5. Eric Christopher. (11 June 2003). "mips eabi documentation".
6. "ArmEabiPort".