An Application Binary Interface (ABI) defines the runtime interfaces
between an executable and the OS under which it is executing. An ABI
consists of the following constituents:

* The native object file format
* System calls
* Dynamic linking

Let's examine these constituents closely.

Object File Format
A typical POSIX operating system uses a single object file format for
all of the applications it runs. These formats include A.OUT, COFF,
XCOFF, and ELF. Other operating systems use their own formats. Windows,
for example, uses the Portable Executable (PE) file format.

System Calls
Operating systems define a set of system calls (some textbooks refer to
these as "API calls"). Applications invoke these syscalls to access
OS-specific services (e.g., file I/O, hardware interfacing, and so on).
Since these syscalls change infrequently from one OS release to another,
you can usually run the same executable under different versions of the
same OS.

Dynamic Linking
Modern operating systems store syscalls' compiled code in shared
libraries. The runtime linking and loading mechanism of the OS resolves
syscalls in the application to the relevant shared libraries at runtime.
Shared libraries also contain the standard libraries of programming
languages such as C and C++. Thus, when you call a library function such
as malloc() or atexit(), the call is eventually resolved to its
corresponding entry in libgc, the shared library of standard C.

Advantages of ABI
Although porting code from one POSIX-compliant OS to another is
relatively easy, you must recompile and re-link the source code before
you can run it on the target OS. By contrast, if two operating systems
(e.g., X and Y) share a common ABI, it's be possible to run on OS Y an
executable that was originally compiled and linked under OS X, and vice
versa.

State of the Art
At present, Linux doesn't have an established ABI. Several attempts to
establish such a standard have been made, such as the LynxOS 4.0 ABI
(http://www.linuxdevices.com/articles/AT8943314364.html); however,
defining an ABI isn't a trivial task. Linux runs on various hardware
architectures that use radically different processors, byte ordering,
and word sizes. Although working around these inherent hardware
incompatibilities is possible by using an intermediate software layer
functioning as an emulator or a virtual machine, the performance
overhead incurred by such solutions has deterred users and kernel
designers alike.

» posted by ITworld staff

ITworld

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine