Arm EABI Port
EABI is the new Extended ABI by Arm ltd. EABI is acually a family of ABI's and one of the "subABIs" is GNU EABI, for Linux. The effective changes for users are:
- Mixing soft and hardfloat code is possible
- Structure packing is not as painful as it used to be
- More compatability with various tools (in future - currently linux-elf is well supported)
- EABI also brings a more efficent syscall method
Gcc view
New ABI is not only a new ABI field, it is also a new GCC target.
Legacy ABI
- GCC abi flags: -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]
Arm EABI:
- GCC abi flags: -mfloat-abi=soft -meabi=4
- gcc -dumpmachine: arm-unknown-linux-gnueabi
- objdump -x for compiled binary:
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. FPA unit has the pecularity of having mixed-endian doubles, which is usually the biggest grief for arm porters (along with struct 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. VFP is implemented in new ARM11 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 unneccesary.
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 a soft-float distribution, where -vfp packages (linux-kernel-2.6.x-vfp, libc6-vfp, mediaplayer-vfp, etc) exist where needed.
...And there is still iwmmmx and maverick floating point units, which we will not cover now...
Struct packing
Todo: explain struct packing issues and Arm alignment
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)
- + apt-get dist-upgrade for users is possible
- - Requires insane amounts of work - every single library package needs to be renamed
- - Requires a very long transition period, in which unstable will be broken for all archs.
- c++ ABI transition takes about half an year, full transition could thus take around 2 years
- - Achieving Consensus for such transition on debian-devel would be very hard.
- Non-Arm developers will object doing such amount of work only for a minor arch. If arm gets dropped from Release Arch's, we can't even file RC bugs for the migration.
- - Very invasive change, affecting every user and developer of Debian.
2. New arch
- + Technically, since we drop FPA instruction support, and gcc dumpmachine triplet is different, we can argue we have a new arch
- + Does not affect non-arm users
- + Can be done quickly, does not affect other arch's release cycle
- + requires less archive space during migration
- - Current arm users don't have a easy upgrade path
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
- + Reflects the packages ABI correctly, would help other transitions as well
- - no working implmentation
- - no consensus on how to do it (apt developers want something more generic instead)
- - might be hard to fit into current archive infrastrucure
- - make dependency resolving hard
From these choices, we believe a new port is the best compromise.
Let's not make perfect an enemy of good!!
EABI status
Riku Voipio has built a booting EABI rootfilesystem up to X as proof of concept, seems stable. Built with codesourcery gcc 3.4 toolchain.
- binutils - already in debian
- gcc - supposed to be in gcc 4.1
- glibc - fully upstream in 2.3.6
- kernel - works already in mainline, some patches still going to be added
- dpkg, apt - patches will be submitted when port name consensus achieved
Naming
Suggested names for the new port
- earm
- arm2
- armel