Application binary interface: Difference between revisions

Revision as of 22:30, 5 November 2007

Latest revision as of 20:33, 13 July 2025

(267 intermediate revisions by more than 100 users not shown)

Line 1:

{{short description|Interface to software defined in terms of in-process, machine code access}}

In [[computer software]], an '''application binary interface''' ('''ABI''') describes the low-level [[interface (computing)|interface]] between an application program and the [[operating system]], between an application and its [[library (computer science)|libraries]], or between component parts of the application. An ABI differs from an [[application programming interface]] (API) in that an API defines the interface between [[source code]] and libraries, so that the same source code will [[compiler|compile]] on any system supporting that API.

{{Use dmy dates|date=June 2020}}

[[File:Linux kernel interfaces.svg|thumb|300px|A high-level comparison of in-kernel and kernel-to-userspace APIs and ABIs]]

[[File:Linux API and Linux ABI.svg|thumb|300px|The [[Linux kernel]] and [[GNU C Library]] define the [[Linux kernel interfaces#Kernel–user space API|Linux API]]. After compilation, the binaries offer an ABI. Keeping this ABI stable over a long time is important for [[Independent software vendor|ISVs]].]]

An '''application binary interface''' ('''ABI''') is an [[interface (computing)|interface]] exposed by [[software]] that is defined for in-[[Process (computing)|process]] [[machine code]] access. Often, the exposing software is a [[Library (computing)|library]], and the consumer is a [[computer program|program]].

For example, the [[POSIX]] standard defines an API that allows a wide range of common computing functions to be written such that they may operate on many different systems ([[Mac OS X]], various [[Berkeley Software Distribution|BSDs]] and [[Microsoft Windows]] all implement this interface), however, making use of this requires [[Compiler|re-compilation]] for each platform. A compatible ABI, on the other hand, allows compiled [[object code]] to function without any changes, on any system implementing that ABI. This is advantagous to both software providers (where they may distribute existing software on new systems without producing/distributing upgrades) and users (where they may install older software on their new systems without purchasing upgrades), although this generally requires various software libraries implementing the necessary APIs too.

An ABI is at a relatively low-level of [[abstraction (computer science)|abstraction]]. Interface compatibility depends on the target [[computer hardware|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 interface at the source code level, before compilation, whereas an ABI defines an interface to compiled code.

Microsoft have shown significant commitment to a backward compatible ABI, particularly within their [[Win32]] library, such that older applications may run on newer versions of Windows. Apple have show less propensity to this concern, expiring compatibility or implementing ABI in a slower "emulation mode"; many argue that this allows greater freedom in development at the cost of obsoleting older software. Among [[Unix-like]] operating systems, there are many related but incompatible operating systems running on a common hardware platform (particularly [[Intel 80386]]-compatible systems). There have been several attempts to standardise the ABI such that software vendors may distribute one binary application for all these systems, however to date, none of these have met with much success. The [[Linux Standard Base]] is attempting to do this for the [[Linux]] platform whilst many of the BSD unices (OpenBSD/NetBSD/FreeBSD) implement various levels of ABI compatablity for both backward compatibility (allowing applications written for older versions to run on newer distributions of the system) as well cross platform compatibility (allowing the execution of foreign code without recompilation).

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 [[programming language|languages]] or when using multiple [[compiler]]s for the same language.

ABIs cover details such as the [[calling convention]], which controls how [[function (programming)|function]]s' arguments are passed and return values retrieved; the [[system call]] numbers and how an application should make system calls to the operating system; and in the case of a complete operating system ABI, the binary format of [[object file]]s, program libraries and so on. A complete ABI, such as the [[Intel]] Binary Compatibility Standard (iBCS),<ref>[http://www.everything2.com/index.pl?node=iBCS Intel Binary Compatibility Standard (iBCS)]</ref> allows a program from one operating system supporting that ABI to run without modifications on any other such system. Other ABIs standardize details such as the [[name mangling#Name mangling in C++|C++ name decoration]],<ref>[http://www.codesourcery.com/cxx-abi/abi.html Itanium C++ ABI] (compatible with multiple architectures)</ref> [[exception handling|exception]] propagation,<ref>[http://www.codesourcery.com/cxx-abi/abi-eh.html Itanium C++ ABI: Exception Handling] (compatible with multiple architectures)</ref> and calling convention between compilers on the same platform, but do not require cross-platform compatibility.

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.

{{Mergefrom|Embedded Application Binary Interface|date=October 2007}}

==See alsoDescription ==

Interface aspects covered by an ABI include:

* [[Programming]]

* [[Processor (computing)|Processor]] [[instruction set]], with details like register file structure, [[Computer memory|memory]] access types, etc.

* [[Opaque pointer]]

* Size, layout, and [[Data structure alignment|alignment]] of basic [[data type]]s that the processor can directly access

* [[PowerOpen Environment]]

* [[Calling convention]], which controls how the arguments of [[function (programming)|function]]s are passed, and return values retrieved; for example, it controls the following:

* [[Embedded Application Binary Interface]]

** 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]]<ref>{{cite web|url=https://itanium-cxx-abi.github.io/cxx-abi/|title=Itanium C++ ABI}} (compatible with multiple architectures)</ref>

* [[exception handling|Exception]] propagation<ref>{{cite web|url=http://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html|title=Itanium C++ ABI: Exception Handling}} (compatible with multiple architectures)</ref>

* How an application should make [[system call]]s to the operating system, and if the ABI specifies direct system calls rather than procedure calls to system call [[Method stub|stubs]], the system call numbers

* In the case of a complete operating system ABI, the binary format of [[object file]]s, program libraries, etc.

ABIs include the [[Intel Binary Compatibility Standard]] (iBCS)<ref>{{cite web |url=http://www.everything2.com/index.pl?node=iBCS |title=Intel Binary Compatibility Standard (iBCS)}}</ref> 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 format]]s, data types, register usage, [[stack frame]] organization, and function parameter passing of an [[Embedded system|embedded]] software program.

Each compiler and [[assembly language|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 [[User space and kernel space|kernel and user space]] typically found in [[desktop computer|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.<ref name="ppc-eabi">{{cite book

| title = PowerPC Embedded Application Binary Interface: 32-Bit Implementation

| date = 1 October 1995

| edition = Version 1.0

| chapter = EABI Summary

| pages = 28&ndash;30

| publisher = Freescale Semiconductor, Inc

| url = http://www.nxp.com/docs/en/application-note/PPCEABI.pdf

}}</ref> The choice of EABI can affect performance.<ref>{{cite web

|title=Debian ARM accelerates via EABI port

|date=16 October 2016

|publisher=Linuxdevices.com

|url=http://linuxdevices.com/news/NS9048137234.html

|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

}}</ref><ref>{{cite web

|author=Andrés Calderón and Nelson Castillo

|title=Why ARM's EABI matters

|date=14 March 2007

|publisher=Linuxdevices.com

|url=http://linuxdevices.com/articles/AT5920399313.html

|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

}}</ref>

Widely used EABIs include the [[PowerPC]],<ref name="ppc-eabi"/> [[Arm architecture|Arm]],<ref>{{cite web|url=https://developer.arm.com/architectures/system-architectures/software-standards/abi |title=ABI for the Arm Architecture |publisher=Developer.arm.com |access-date=4 February 2020}}</ref> and [[MIPS architecture|MIPS]] EABIs.<ref>{{cite mailing list |url=https://sourceware.org/legacy-ml/binutils/2003-06/msg00436.html |author=Eric Christopher |title=mips eabi documentation |mailing-list=[e-mail] |date=11 June 2003 |access-date=19 June 2020}}</ref> 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.<ref>{{cite web |title=ArmEabiPort |url=https://wiki.debian.org/ArmEabiPort |website=Debian Wiki |quote=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.}}</ref>

== See also ==

{{Portal|Computer programming}}

* {{Annotated link|Binary-code compatibility}}

* {{Annotated link|Bytecode}}

* {{Annotated link|Comparison of application virtualization software}}

* {{Annotated link|Debug symbol}}

* {{Annotated link|Foreign function interface}}

* {{Annotated link|Language binding}}

* {{Annotated link|Native (computing)}}

* {{Annotated link|Opaque pointer}}

* {{Annotated link|PowerOpen Environment}}

* {{Annotated link|Symbol table}}

* {{Annotated link|SWIG}}

* [[Visual C++#Compatibility|Visual C++ Compatibility]]

==References==

{{reflistReflist|30em}}

== External links ==

* [https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B Policies/Binary Compatibility Issues With C++]{{snd}} a compendium of development rules of thumb for not breaking binary compatibility between library releases

* [http://www.arm.com/products/DevTools/ABI.html Application Binary Interface (ABI) for the ARM Architecture]

* [https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/LowLevelABI/000-Introduction/introduction.html OS X ABI Function Call Guide]

* [http://www.cygwin.com/ml/binutils/2003-06/msg00436.html MIPS EABI documentation]

* [http://wiki.debian.org/ArmEabiPort Debian ARM EABI port]

* [http://www.uclibc.org/ μClib: Motorola 8/16-bit embedded ABI]

* {{webarchive|url=https://web.archive.org/web/20080528070803/http://www.x86-64.org/documentation.html|title=AMD64 (x86-64) Application Binary Interface}}

* [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0036b/index.html Application Binary Interface (ABI) for the ARM Architecture]

* [https://sourceware.org/legacy-ml/binutils/2003-06/msg00436.html MIPS EABI documentation]

* {{webarchive|url=https://web.archive.org/web/20150114065444/http://www.oracle.com/technetwork/server-storage/solaris10/about-amd64-abi-141142.html|title=Sun Studio 10 Compilers and the AMD64 ABI}}{{snd}} a summary and comparison of some popular ABIs

* [https://www.nxp.com/docs/en/reference-manual/MCOREABISM.pdf M•CORE Applications Binary Interface Standards Manual] for the Freescale [[M·CORE]] processors

{{Application binary interface}}

[[Category:Application programming interfaces]]

[[Category:Operating system technology]]

[[cs:ABI]]

[[de:Binärschnittstelle]]

[[it:Application binary interface]]

[[ja:Application Binary Interface]]

[[no:Binærkompatibilitet]]

[[pl:ABI]]

[[pt:Interface binária de aplicação]]

[[ru:Двоичный интерфейс приложений]]

[[zh:应用二进制接口]]