Arm EABI Port

EABI is the new "Embedded" ABI by Arm ltd. EABI is actually a family of ABI's and one of the "subABIs" is GNU EABI, for Linux. The effective changes for users are:

Gcc view

New ABI is not only a new ABI field, it is also a new GCC target.

Legacy ABI

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

Arm EABI:

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

ARM floating points

Current debian port creates hardfloat FPA instructions. FPA comes from "Floating Point Accelerator". Since 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 inefficent: about 10 times slower that -msoftfloat for a FIR test program. The FPA unit also has the pecularity of having mixed-endian doubles, which is usually the biggest grief for arm porters, along with structure packing issues.

In their great wisdom, ARM has introduced a new floating point unit, VFP (Vector Floating Points), which uses a different instruction set than FPA and stores floats in natural-endian IEEE-754 format. VFP is implemented in new some ARM9/10/11 cores, like in the new TI OMAP2 family. It seems likely that arm cores without VFP will remain popular, as in many places ARM is used floats are unnecessary.

Some ARM processors include Cirrus Logic's Maverick Crunch unit. This also uses IEEE-754, though uses a differnt instuction set to VFP. It is used in their EP93XX series of system-on-chip devices with an ARM920T main core.

Intel's iWMMX unit is used in their PXA270 processor with an XScale main core. This adds integer SIMD and some other instructions. It does not have any hardware floating point capabilities.

Current ARM-Debian users cannot use their Maverick FPUs at all except by programming in assembler. GCC has flags to generate Maverick FP instructions, but the .o files cannot be linked with the GCC startup files or libraries.

For a generic-purpose distribution like Debian, targetting binary compatability (as opposed to source-based distributions that currently are more popular among Linux systems), EABI lets us have the cake and eat it. We can make a soft-float distribution using IEEE-754, where -vfp packages (linux-kernel-2.6.x-vfp, libc6-vfp, mediaplayer-vfp, etc) exist where needed, or individual packages can do runtime FPU detection.

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 teh 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, can break code that writes binary files by dumping and reading structures.

64-bit data type alignment

"One of the key differences between the traditional GNU/Linux ABI and the EABI is that 64-bit types (like long long) are aligned differently. In the traditional ABI, these types had 4-byte alignment; in the EABI they have 8-byte alignment. As a result, if you use the same structure definitions (in a header file) and include it in code used in both the kernel and in application code, you may find that the structure size and alignment differ."

Enum sizes

The EABI defines an optional system for controling the size of C enumerated types. For arm-linux it was decided to keep the existing behavior (enums are at least the same size as an int) for consistency with other linux systems.

System call interface

One area affected by alignment/struct packing is the few system calls that pass structures or 64-bit types. To solve this problem a new kernel syscall interface has been introduced. EABI kernels have an option to support the old syscall interface (including old structure layout rules) for running non-eabi binaries. However some features (eg. ALSA) do not have the necessary kernel shims, so will only work correctly from EABI binaries.

Some third party EABI toolchains (eg. CodeSourcery 2005q3) use the old kernel interface via userspace shims in glibc. This is now obsolete and no longer supported by glibc.

Thumb interworking

The EABI includes thumb interworking. ('Thumb interworking' means that thumb and normal arm instructions can be mixed (at function granularity)). With current gcc this requires at least an armv4t core, because it uses the BX instruction which does not exist in armv4 or earlier. Currently mixing Thumb code and Shared libraries only works on armv5t cores.

Thumb interworking requires every return and indirect function call execute BX instruction (or LDR/LDM on armv5t) to set the core to the correct state. Paul Brook suggested using

tst lr, #1; moveq pc, lr; bx lr

(as an alternative to BX) Which should allow running on older, thumbless cores (such like ?StrongArm), with the extra cost of two instructions per indirect call/function return.

Why a new port

In Debian, we want to assure complete binary compatablity. Since the old ABI is not compatible with the new one, we can't allow packages built with old ABI to link against new-abi libs, or the other direction. So the options are:

0. Not an option!

Under no circumstances distribute EABI binaries as .arm.deb depending on current library package names!!!

1. Rename all library packages

This is the ABI transitions affecting all architectures have been done (aout -> elf, c++ ABI)

2. New arch

For the last point, a statically compiled ?ArchUpgrade tool could be created. This would also allow i386->amd64 style migrations.

3. ABI: field in control file

This was suggested as part of Multiarch proposal. It is unknown if it would actually become part of Debian or not

From these choices, we believe a new port is the best compromise.

4. conflicting libc packages

In this scenario, we create a libc6-eabi(-dev) package that has eabi glibc and ld-linux.so.3. This package will conflict with libc6(-dev), and thus you can mix and match eabi and non-eabi binaries and libs.

Let's not make perfect an enemy of good!!

EABI status

CodeSourcery provide http://www.codesourcery.com/gnu_toolchains/arm/download.html GNU ARM toolchains that are modified versions of gcc-3.4.4. However these toolchains do not (yet) use the EABI kernel interface.

gcc 4.1.0 supports the arm*-*-linux-gnueabi target.

EABI is supported in the ARM Linux kernel from version 2.6.16 and there is a binfmt module to allow the running of old-ABI binaries with an EABI kernel. The inverse module, to run EABI binaries in an ABI kernel, is not implemented and is said to be non-trivial to do.

Riku Voipio has built a booting EABI rootfilesystem up to X as proof of concept, which seems stable, built with codesourcery gcc 3.4 toolchain.

Naming

update: since dpkg in etch, gnueabi-arm is pretty much the only choice.

Suggested names for the new port.