This page has been superceded by http://wiki.debian.org/Multiarch/Tuples
It remians only for historical interest
Discussion of new ABI labels for multiarch from Debconf10
It has became clear in recent detailed discussions about the implementation of multiarch that the GNU triplet is not sufficient to cover all necessary cases. There were a couple of meetings at DebConf10 amongst interested people to work out a naming scheme that would work. These are the notes that came out of that event.
Agenda
- agree on the structure of the tuples
- come to a consensus on which scheme to use for the initial machine values covering existing Debian ports
- determine the names to use for the syscall, ABI portions of the tuple for the existing Debian ports
- work plan
- software and documentation deliverables
Attendees
- vorlon
- wookey
- doko
- aurel32
- aloiret
- lool
Tuple structure
/lib/<cpuish name>-<syscall abi>-<calling conventions and libc abi>?
- cpuish bit: unique identifier for machine, wordsize, and endianess, allocated by an independent entity
name
CPU
endianess
wordsize
arm
arm
le
32
armeb
arm
be
32
alpha
alpha
le
64
avr32
avr32
be
32
hppa
hppa
be
32
ia64
ia64
le
64
m68k
m68k
be
32
mips
mips
be
32
mips64
mips
be
64
mipsel
mips
le
32
mips64el
mips
le
64
ppc
powerpc
le
32
ppc64
powerpc
le
64
s390
s390
be
32
s390x
s390
be
64
sparc
sparc
be
32
sparc64
sparc
be
64
sh4
sh4
le
32
sh4eb
sh4
be
32
sh4
sh4
le
32
x86_64
x86_64
le
64
- cpuish bit: unique identifier for machine, wordsize, and endianess, allocated by an independent entity
How to do with armhf (armv7 + neon only) and powerpcspe (no FPU, SPE, no lwsync instruction, slightly different ABI than powerpc on long double only)?
- syscall abi: kernel and its personality / syscalls calling conventions; e.g. linux, linuxeabi
name
cpuish
personality
notes
linux
arm*
linux32
Arm linux syscalls from 2.6.16 onwards
linuxapcs?
arm*
linux
Arm syscalls default prior to version 2.6.16 (CONFIG OABI afterwards)
linux
mips
linux
linux
mips64
linux
linuxn32
mips64
linux
freebsd
?
gnu
?
Hurd
- calling conventions and libc abi: e.g. GNU EABI versus old ABI userspace calling conventions(on arm), and name of libc or none if no libc is use
name
description
glibc(gnu?)
glibc
gnu_n32
glibc, MIPS n32 ABI
gnu_n64
glibc, MIPS n64 ABI
gnu_hf?
glibc,hardfloat ABI
uclibc
uclibc
none
baremetal
- optional instruction set components (eg floating point units, multimedia instructions) are not described in this mechanism - that is left to HWCAPS type mechanisms. This is only for incompatible calling conventions.
- e.g. (examples superseded by the above, FIXME): /lib/x86-linux-glibc, /lib/x86_64-linux-glibc /lib/armeb-freebsd-glibc, /lib/x86-gnu-glibc, /lib/powerpc-linux-uclibc /lib/arml-linux-gnuhf, /lib/armb-linux-gnusf, /lib/arml-linux-uclibc /lib/arm-linux-none (statically linked), /lib/mips64-linux-gnun32
- could do sub directories for each glibc with only arch+kernel; or can require -none for statically linked binary
- what is a machine, and what is an ABI?
- where do we encode endianness?
- if there's no libc, we can't put it in the libc+ABI field if we're using 'none' as the value of this field; so put it in the machine field
- where do we encode endianness?