Differences between revisions 23 and 24
Revision 23 as of 2006-03-10 19:56:38
Size: 10548
Editor: nchip
Comment:
Revision 24 as of 2006-03-16 13:06:33
Size: 10201
Editor: MartinGuy
Comment: Fix URL typo and remove confusion now that it's explained
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:
 * EABI also brings a more efficent [http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3105/4:syscall convention]  * EABI also brings a more efficent [http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3105/4 syscall convention]
Line 24: Line 24:
 * ABI flags passed to binutils: -mfloat-abi=soft -meabi=4  * ABI flags passed by gcc to binutils: -mfloat-abi=soft -meabi=4
Line 31: Line 31:
''Confused of Newcastle writes: Huh? -meabi does not
seem to exist in GCC-4.1.0 20060127, where -meabi only exists as an unfortunately synonymous powerpc option.
See paragraph in "EABI Status" below. Is -meabi=4 in the CodeSourcery GCC-3.4.4?''
  ''["nchip"]: These are flags gcc passes to binutils to tell what abi to use, not flags given to gcc ''

Arm EABI Port

EABI is the new Extended 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:

["nchip"] How to check that the new syscalls are in use? In my rootfs they clearly weren't, as it worked with 2.6.12 kernel..

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]

Arm EABI:

  • ABI flags passed by gcc to binutils: -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: 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 little-endian IEEE-754 format. 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 unnecessary.

ARM processors also come with two other floating point coprocessors, both with different instruction sets from FPA or VFP:

  • Cirrus Logic's Maverick Crunch unit, which also uses IEEE-754, used in their EP93XX series of system-on-chip devices with an ARM920T main core, and
  • Intel's iWMMX unit, used in their PXA270 processor with an XScale main core. This adds some MMX, some SSE and some other instructions to the set. It too seems to use IEEE-754.

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.

Similarly, GCC can generate Thumb instructions on a per-file basis, but because of startup/library issues, this is only usable in self-contained leaf code files that call no standard library routines or floating point (which generates library routine calls) thus making it useless for its main purpose of reducing the size of bulk code in storage-limited systems.

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). 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, and means that the interface to the kernel changes for the few system calls that pass structures or 64-bit data types.

Structure packing

"Structure packing changes" they say, but no one seems to know in what way...

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

EABI defaults to -fshort-enums. So if rtl.h has this:

  /* The kind of expression this is.  */
  ENUM_BITFIELD(rtx_code) code: 16;

but there are only 164 RTL codes, the underlying type of enum rtx_code is "char" and GCC gives an error that the bitfield is wider than its type.

(Edited from [http://gcc.gnu.org/ml/gcc/2004-12/msg00325.html an article in the GCC mailing list])

System call interface

One area affected by alignment/struct packing is the few system calls that pass structures or 64-bit types. This makes the old-abi and new-abi kernel interfaces incompatible, meaning that you cannot run EABI userland binaries on a kernel compiled with old ABI.

Several workarounds exist: * The "glibc shims" approach is a set of patches to glibc. They allow you to make a toolchain that generates EABI executables that run on ABI kernels by rearranging EABI structures into old-ABI format just before each system call, and remunging the return values on the way back up. This ingenious hack is now deprecated. * The latest ARM EABI kernels have a binary-compatability (binfmt) module that can run old ABI executables.

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
  • + we can target EABI for armv5+ while we can can keep oldabi port for strongarm etc 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.

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.

  • + similar to the libc6.1 style packages on some archs
  • + requires modifying only glibc
  • - ugly
  • - most arm of arm port will remain unistallable for long time
  • - apt-get dist-upgrade will still not work, since it gives up quicly when lots of packages conflics

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.

The ?ChangeLog in gcc-4.1.0 20060127 (prerelease) says that target arm*-*-linux-gnueabi was added on 2004-11-19, though it is not available as a new -mabi= option.

EABI is supported in the ARM Linux kernel from version 2.6.12 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.

  • 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

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

Suggested names for the new port.

  • gnueabi-arm
  • earm
  • arm2
  • armel