Application binary interface

A high-level comparison of in-kernel and kernel-to-userspace APIs and ABIs
Linux kernel and GNU C Library define the Linux API. After compilation, the binaries offer an ABI; keeping this ABI stable over a long time is important for ISVs.

In computer software, an application binary interface (ABI) is the interface between two program modules, one of which is often a library or operating system, at the level of machine code. An ABI determines such details as how functions are called and in which binary format information should be passed from one program component to the next, or to the operating system in the case of a system call.

Adhering to ABIs (which may or may not be officially standardized) is usually the job of the compiler, OS or library writer, but application programmers may have to deal with ABIs directly when writing programs in a mix of programming languages, using foreign function call interfaces between them.

ABIs differ from application programming interfaces (APIs), which similarly define interfaces between program components, but at the source code level.

Description

ABIs cover details such as:

A complete ABI, such as the Intel Binary Compatibility Standard (iBCS),[1] allows a program from one operating system supporting that ABI to run without modifications on any other such system, provided that necessary shared libraries are present, and similar prerequisites are fulfilled.

Other ABIs standardize details such as the C++ name mangling,[2] exception propagation,[3] and calling convention between compilers on the same platform, but do not require cross-platform compatibility.

Embedded-application binary interface

An embedded-application binary interface (EABI) specifies standard conventions for file formats, data types, register usage, stack frame organization, and function parameter passing of an embedded software program.

Compilers that support the EABI create object code that is compatible with code generated by other such compilers, allowing developers to link libraries generated with one compiler with object code generated with another compiler. Developers writing their own assembly language code may also use the EABI to interface with assembly generated by a compliant compiler.

The main differences between an EABI and an ABI for general-purpose operating systems are that privileged instructions are allowed in application code, dynamic linking is not required (sometimes it is completely disallowed), and a more compact stack frame organization is used to save memory.[4] The choice of EABI can affect performance.[5][6]

Widely used EABIs include PowerPC,[7] ARM EABI2[8] and MIPS EABI.[9]

See also

References

  1. ↑ Intel Binary Compatibility Standard (iBCS)
  2. ↑ Itanium C++ ABI (compatible with multiple architectures)
  3. ↑ Itanium C++ ABI: Exception Handling (compatible with multiple architectures)
  4. ↑ "EABI Summary". PowerPC Embedded Application Binary Interface: 32-Bit Implementation (PDF) (Version 1.0 ed.). Freescale Semiconductor, Inc. 1995-10-01. pp. 28–30.
  5. ↑ "Debian ARM accelerates via EABI port". Linuxdevices.com. 2007-01-19. Archived from the original on 21 January 2007. Retrieved 2007-10-11.
  6. ↑ Andrés Calderón and Nelson Castillo (2007-03-14). "Why ARM's EABI matters". Linuxdevices.com. Archived from the original on 31 March 2007. Retrieved 2007-10-11.
  7. ↑ "PowerPC Embedded Processors Application Note"
  8. ↑ "ARM Information Center". Infocenter.arm.com. Retrieved 2014-02-27.
  9. ↑ "Eric Christopher - mips eabi documentation". Cygwin.com. 2003-06-11. Retrieved 2014-02-27.

External links

This article is issued from Wikipedia - version of the Thursday, February 18, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.