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

* 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)

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 and how do I use it?

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 here.
    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 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.

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).

2: ABI translation

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.

Re: 关于kernel ARM_EABI

EABI是ARM公司后来推出的一个ABI 叫Embeded ABI 原来旧的就
被叫做 Old-ABI或者Legacy-ABI
在OABI下 这些函数都通过一个系统调用实现 sys_ipc 在EABI
下把它们拆开了 所以任何一种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

- 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?

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.

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


2。什么是OABI 和 EABI

3。EABI的好处 / 为何要用EABI

D。结构体中的 填充(padding/packing)和对齐。

个人分类: ARM-Linux移植
想对作者说点什么? 我来说一句