Re: armelfp: new architecture name for an armel variant
+++ Wookey [2010-07-06 19:36 +0100]:
> +++ Hector Oron [2010-07-06 19:30 +0200]:
> There are of course many possible ABI, FPU and instruction-set options
> possible on ARM (far too many in fact). Which ones it is worthwhile
> supporting in Debian is an interesting question. It would be good to
> keep the number of incompatible architectures as low as possible and
> use other mechanisms to allow the use of CPU features when present.
> There are fields in the elf headers to indicate cababilities used in a
> binary which are not currently used by the compiler which would help
> in automatically ensuring that CPUs do not try to run code they can
> (because it has FPU or NEON instructions and those units are not
> present, for example). Toolchain and loader changes are needed to make
> that a reality, but that's better than an explosion of
> Having two arches: for the incompatible softfp and hardfp ABIs makes
As well as the debian arch name there is the question of the
corresponding GNU triplet name.
I have spent much of today looking at what we have, what is coming
from ARM in the future and if there is any room for rationalisation of
the namespace or some future-proofing whilst we ar making changes.
It's an ugly subject :-)
The first thing I've found is that whilst we can build for
--mfloat-abi=hard there is no macro set by GCC to detect this state.
Currently we have __SOFTFP__ and __VFP_FP__ defined. The first is set
when there is no FPU at all so only softemulation routines will be
used. The second indicates that the EABI sensible-endian FP format is
being used (i.e not the old-abi mixed-endian one). Nothing says which
FP calling convention is being used. If anything needs patching for
this change then we need to be able to check this status during build.
Fortunately the hopefully-soon-to-be-finalised ARM C language
extension spec defines a macro we can use: __ARM_PCS_VFP__ so if we
use that then we'll be compatible with other compilers. (I did also
discover whilst checking this that __SOFTFP__ in gcc and __SOFTFP__ in
ARM's proprietary compiler don't mean the same thing (oops!).
So I suggest anyone doing patching use that, and we'd better get a
patch into gcc sharpish to set it when building for this ABI.
The triplet conversation is more complicated. The gnu triplet
originally comes from config.guess and is there to define the overall
class of architecture/vendor/os/abi, especially where that cannot be
determined interactively, e.g when building cross-compilers.
The parts are (in principle): cpu, manufacturer, kernel, OS but these
classifications are showing their age and the meanings are somewhat
either redundant or overloaded these days. A look at
dpkg/ostable,cputable,triplettable and config.guess and the set of
things output by uname -a on arm boxes will show how this has all got
manufacturer/vendor doesn't really supply useful information these
days and is usually none or omitted.
cpu is the base architecture. On arm the kernel supplies a range of
things like armv4t arm v3 armv5tej armv7a i.e it specifies the
architecture level and the instruction set extensions available. It
does not list the co-processors available ( e.g VFP3, SIMD (Neon)).
Perhaps it should if we wanted this string to specify the
instruction-set available, but the names start to get rather long.
Some machines add a 'b' to this string for big-endian, which isn't
really a feature of the cpu - it's an ABI thing, and it almost
certainly shouldn't be in here.
There is a train of thought which would like to rename the
architecture string to 'aarch' from 'arm' (standing for 'arm
architecture'), to distinguish the architecture from the company. I
think it's a bit late for that :-)
kernel is kernel - linux or bsd in Debian.
OS has been overloaded to include the ABI since the OABI ('gnu') EABI
('gnueabi') split. This isn't very pretty, but despite thinking about
it for a while I haven't had any better ideas. I don't think that
re-purposing the vendor/manufacturer field would really work, and
adding a 5th field would also be a lot of pain (there are a lot of
regexps in a lot of software to fix up). But if anyone does think it's
a good idea then I don't mind taking a look at the practicalities.
The set of incompatible ABI options (as opposed to instruction set
options) we have is:
hard-float/soft-float calling convention
Clearly most of those 8 combinations are not needed. There have been
two OABI variants so far and one EABI. ( The OABI big-endian port was
only ever unofficial and short-lived so there is no need to keep
compatibiity, althugh we should be aware that there are plenty of
'ARMEB' strings inside debian sources which might confuse a modern
hacker). The need for big-endian building of the whole distro (only
ever favoured by ethernet-packaet-obsessed people and people stuck
with binary big-endian drivers) is much reduced on newer cpu
architectures that have a byte-swap instruction. But maybe someone
will come up with a good excuse for a big-endian port again one day.
Best to cater for it if it's ot intrusive.
So those options might be named with single-letter indicators:
That is perhaps a bit too cryptic, so maybe:
and maybe losing the existing 'eabi' moniker would cause too much
trouble, as would having an alias for the existing EABI, soft-float
port, so that leaves us with:
If anyone tried to use 'armeb' it's almost certinaly time to declare
that as EABI as otherwise everything is just too confusing.
I would be good if the target-ABI setting was separated out from the
OS string somehow, but doing that is a significant undertaking of
changes in a lot of places. There is no shortage of namespace in the
OS field so we can carry on making up new names for quite some time,
but the regexp tables get very ugly if we are not systematic about it.
One last thing is that if doing a new ABI flavour with corresponding
breakage, then that would be a good time to put in a couple of
incompatible EABI improvements which have been waiting for an
opportunity. That would require quick spec and toolchain changes. I'll
post more about that if it materialises.
I guess that's (more than) enough for now. Thoughts welcome.
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM