ARM ELF and ABI
In computing, the Executable and Linkable Format (ELF, formerly called Extensible Linking Format) is a common standard file format for executables, object code, shared libraries, and core dumps. First published in the System V Application Binary Interface specification,[1] and later in the Tool Interface Standard,[2] it was quickly accepted among different vendors of Unix systems. In 1999 it was chosen as the standard binary file format for Unix and Unix-like systems on x86 by the 86open project.
Unlike many proprietary executable file formats, ELF is flexible and extensible, and it is not bound to any particular processor or architecture. This has allowed it to be adopted by many different operating systems on many different platforms.
The ELF file format is also used as a generic object and executable format for binary images used with embedded processors like AVR.
Each ELF file is made up of one ELF header, followed by file data. The file data can include:
- Program header table, describing zero or more segments
- Section header table, describing zero or more sections
- Data referred to by entries in the program header table or section header table
The segments contain information that is necessary for runtime execution of the file, while sections contain important data for linking and relocation. Any byte in the entire file can be owned by at most one section, and there can be orphan bytes which are not owned by any section.
ABIs cover details such as:
- data type, size, and alignment
- the calling convention, which controls how functions' 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 files, program libraries and so on. which ELF means
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.
An ABI should not be confused with an application programming interface (API) which defines a library of routines to call, data structures to manipulate, and/or object classes to use in the construction of an application using that particular (often language specific) API.
in fact, ABI is about object files , and API is about source files, as API of C source file is depend on functions.
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, thus allowing developers to link libraries generated with one compiler with object code generated with a different 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 of an EABI with respect to 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]
Widely used EABIs include PowerPC[5] and ARM.
object files has three format:
relocable files, excutable files , shared files