ABI/EABI/OABI 

(..............................)

Terminology

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. However, there are one or two programs that sometimes describe an old ABI binary as "EABI".

To add to the confusion, 

powerpc has also had an ABI called "EABI" for some, which has nothing to do with this one.

(..............................)

GCC view

New ABI is not only a new ABI field, it is also a 

new GCC target.

Legacy ABI

* ABI flags passed to binutils: -mabi=apcs-gnu -mfpu=fpa

* gcc -dumpmachine: arm-unknown-linux

* objdump -x for compiled binary:

private flags = 2: [APCS-32] [FPA float format] [has entry point]

* "file" on compiled Debian binary:

ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), for GNU/Linux 2.2.0, stripped

* "readelf -h | grep Flags""

Flags: 0x0

Arm EABI:

* ABI flags passed by gcc to binutils: -mabi=aapcs-linux -mfloat-abi=soft -meabi=4

* gcc -dumpmachine: arm-unknown-linux-gnueabi

* objdump -x for compiled binary:

private flags = 4000002: [Version4 EABI] [has entry point]

* "file" on compiled binary (under Debian):

ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.4.17, dynamically linked (uses shared libs), for GNU/Linux 2.4.17, stripped

* "readelf -h | grep Flags""

Flags: 0x4000002, has entry point, Version4 EABI

Furthermore, as well as the usual __arm__ and maybe also __thumb__ symbols, the C preprocessor symbol 

__ARM_EABI__ is also defined when compiling into EABI.

(..............................)

Struct packing and alignment

With the new ABI, 

default structure packing changes, as do some default data sizes and alignment (which also have a knock-on effect on structure packing). In particular the minimum size and alignment of a structure was 4 bytes. 

Under the EABI there is no minimum and the alignment is determined by the types of the components it contains. This will break programs that know too much about the way structures are packed and can break code that writes binary files by dumping and reading structures.

(..............................)

application binary interface (ABI) describes the low-level interface between an application program and the operating system, or the interface between an application and its libraries, or that between component parts of an application. An ABI is similar to an application programming interface (API); however, the latter defines a source code interface.[1] Simply put, ABIs enable binary compatibility, whereas APIs enable source code compatibility.

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 BSDs and Microsoft Windows all implement this interface); however, making use of this requires 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 advantageous 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.

ABIs cover details such as 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. A complete ABI, such as the Intel Binary Compatibility Standard (iBCS),[2] 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 C++ name decoration,[3] exception propagation,[4] and calling convention between compilers on the same platform, but do not require cross-platform compatibility.

What is EABI?

GNU EABI is a new application binary interface (ABI) for Linux. It is part of a new family of ABI's from ARM� Ltd. known in the arm-linux community as EABI (or sometimes Embedded ABI).

How do I use EABI?

To use EABI, you'll need:

• A linux kernel that supports EABI. All BitsyG5 kernels and boards that run the latest 2.6 kernel are configured with EABI support enabled. You can boot these kernels from an ATA flash card or on-board flash just as you would our regular kernels.
  
• An EABI root file system based on ADS' new Debian port which is available for download .
  You can install this root on an NFS server or harddrive, just as you would our regular full Debian distribution.

The root file system includes an arm-linux-gnueabi toolchain which you can use to recompile your own source code.

Why switch to EABI?

According to   the new EABI:

• Allows mixing softfloat and hardfloat code.
  
• Uses a more efficient syscall convention.
  
• Will be more compatible with future tools.

Furthermore, the GCC default for EABI will be to use softfloat instructions for floating point arithmetic.

Traditionally, GCC used hardfloat FPA 

^[1] instructions in arm-linux software. Unfortunately, most ARM processors lack support for FPA and instead rely on the kernel for floating point emulation (FPE). They do this through illegal instruction faults which are rather inefficient. Emulating floating point instructions using softfloat is significantly faster than the standard NWFPE used in most arm-linux kernels and appreciably faster than the FastFPE we use in our kernels.

Like most root file systems for ARM computers, Debian uses GCC's default for floating point operations. Prior to the introduction of EABI, the only way to use softfloat was to recompile the entire root file system with softfloat enabled. Now, with an EABI root file system, softfloat instructions will be used by default 

and you'll be able to mix hard and soft float executables.

In the absence of FPA hardware, the switch to softfloat alone will offer appreciable performance improvement. Additionaly, if your system has some non-FPA floating point hardware, you can recompile critical software with the appropriate hardfloat instructions for an even greater improvement in performance and still be able to run it alongside software that uses softfloat.

Besides FPA, what other intruction sets are there ?

We have or will have systems that use VFP (Vector Floating Points), Maverick Crunch (Cirrus Logic), and iWMMXt (Intel) instructions. (The iWMMXt instructions are actually integer SIMD instructions but their opcodes overlap those for FPA).

Why ARM's EABI Matters

The ARM EABI (embedded application binary interface) improves the floating point performance. So, it's not striking if you read how your processor is wasting a lot of cycles now. From the Debian ARM-EABI wiki:

The current Debian port creates hardfloat FPA instructions. FPA comes from "Floating Point Accelerator". Since the FPA floating point unit was implemented only in very few ARM cores, these days FPA instructions are emulated in kernel via Illegal instruction faults. This is of course very inefficient: about 10 times slower that -msoftfloat for a FIR test program. The FPA unit also has the peculiarity of having mixed-endian doubles, which is usually the biggest grief for ARM porters, along with structure packing issues.

So, what does it mean? It means that the compilers usually generate inscructions for a piece of harware, namely a Floating Point Unit that is not actually there!

So, when you make a floating point operation, such at 3.58*x, the CPU runs into an illegal instruction, and it raises an exception.

The kernel catches this specific exception and performs the intended float point operation, and then resumes executing the program. And this is slow because it implies a context switch.

EABI是ARM公司后来推出的一个ABI 叫Embeded ABI 原来旧的就

被叫做 Old-ABI或者Legacy-ABI

在OABI下 这些函数都通过一个系统调用实现 sys_ipc 在EABI

下把它们拆开了 所以任何一种ABI下对功能都没影响

下面是两种ABI在系统调用时的区别

以 long ftruncate64(unsigned int fd, loff_t length) 为例:

legacy ABI:

- put fd into r0

- put length into r1-r2

- use "swi #(0x900000 + 194)" to call the kernel

new ARM EABI:

- put fd into r0

- put length into r2-r3 (skipping over r1)

- put 194 into r7

- use "swi 0" to call the kernel

Q3: What are OABI and EABI?

A3: They are two kinds of 

ABI (Application Binary Interface). The ‘

O’ stands for ‘

Old’, and the ‘

E’ means ‘

Embedded’, a new approach to API for portable devices like the Zaurus.

GNU EABI is a new application binary interface (ABI) for Linux. It is part of a new family of ABI's from ARM® Ltd. known in the arm-linux community as EABI (or sometimes Embedded ABI).

According to Debian Wiki the new EABI:

* Allows mixing softfloat and hardfloat code.

* Uses a more efficient syscall convention.

* Will be more compatible with future tools.

Furthermore, the GCC default for EABI will be to use softfloat instructions for floating point arithmetic.

1。什么是ABI
ABI，application binary interface (ABI)，应用程序二进制接口。
既然是 接口，那就是某两种东西之间的沟通桥梁，此处有这些种情况：
A。应用程序 <－> 操作系统；
B。应用程序 <－> （应用程序所用到的）库
C 。应用程序各个组件之间

类似于API的作用是使得程序的代码间的兼容，ABI目的是使得程序的二进制（级别）的兼容。

2。什么是OABI 和 EABI
OABI中的O，表示“Old”，“Lagacy”，旧的，过时的，OABI就是旧的/老的ABI。
EABI中的E，表示“Embedded”，是一种新的ABI。
EABI有时候也叫做GNU EABI。
OABI和EABI都是专门针对ARM的CPU来说的。

3。EABI的好处 ／ 为何要用EABI
A。支持软件浮点和硬件实现浮点功能混用
B。系统调用的效率更高
C。后今后的工具更兼容
D。软件浮点的情况下，EABI的软件浮点的效率要比OABI高很多。

4。OABI和EABI的区别
两种ABI在如下方面有区别：
A。调用规则（包括参数如何传递及如何获得返回值）
B。系统调用的数目以及应用程序应该如何去做系统调用
C。目标文件的二进制格式，程序库等
D。结构体中的 填充（padding/packing）和对齐。