I have been working on arm64 ILP32 bootstrapping (in debian) for some
time now (sporadically), and in doing so noticed that we (ARM) did not
choose the best triplet. After internal discussion we have decided
that it would be better if it was changed, if possible. The technical
case for this is set out below.
Changing it is only sensible if there is consensus across distros and
upstreams that this is the right way to go, so comment is being
solicited here. If people have good reasons why it is worth the extra
work and difference from x86 practice involved in keeping the
existing triplet, then we can do that.
The existing triplets (big+little endian) are:
aarch64_ilp32-linux-gnu
aarch64_be_ilp32-linux-gnu
The proposed new triplets are:
aarch64-linux-gnu_ilp32
aarch64_be-linux-gnu_ilp32
The reasoning for changing is as follows.
The main technical argument is:
* ILP32 is an ABI, not a machine/kernel feature. So it makes more
sense to put the ILP32 indicator in the 'ABI' part of the triplet
than the 'kernel/machine' part of the triplet. No kernel will ever
return 'aarch64_ilp32' via uname (only 'aarch64' or 'aarch64_be').
Any aarch64 machine, with a new-enough kernel, can run LP64 or
ILP32 code. The kernel/hardware really doesn't care. Which you
choose/want is a feature of the userspace, more specifically of the
glibc and/or gcc defaults in place, (gcc defaults optionally
overridden with a -mabi option). Thus it makes sense to say "this
userspace is 'gnu_ilp32' ABI", when building/configuring software.
The main practical arguments are:
* We don't have to change config.sub/guess in every autoconfed piece
of software in the world to get our new ABI recognised. To use
aarch64_ilp32-linux-gnu requires config.sub and config.guess to be
updated in every autoconf-using package, and no autoconf update has
even gone upstream yet so this will take years. If we use
aarch64-linux-gnu_ilp32 instead, autoconf 'just works' already without
any changes, as abi suffixes are passed-through.
This is the thing that will significantly reduce the effort of building
an ILP32 userspace.
* The x86 'x32' ABI is exactly analagous to the aarch64 ilp32 ABI,
and they chose to use an ABI suffix: 'x86_64-linux-gnux32'
Avoiding gratuitous difference from x86, in the exact same
situation, without any technical justification for divergence, is
sensible. More stuff should just work, like the autoconf case, or
at least be fixed in the same way, so porting is easier. Being
gratuitously different is both confusing to people and likely to
make more porting work (but I don't have a good handle on how much
more, beyond autoconf-using packages).
We do insist on an '_' separator, because separators are good for
both clarity and parsing. (i.e gnu_ilp32, not gnuilp32)
We realise that it is rather late in the day for this change, as some
people have been using the existing triplet in toolchains already, but
the kernel and glibc ABI was only relatively recently settled and
patches submitted, there is no autoconf support yet upstream, and the
toolchain support is incomplete in that you can't actually build a
self-hosted ilp32-defaulting toolchain yet, so we believe that it is
not actually too late, and worth trying to fix this now in the
interests of a simpler porting process in the long term.
The set of people who actually use ILP32 at this early stage, and thus
care, is currently quite small, but we would like to hear from anyone
who has baked the existing triplet into something and maybe released
it, such that this change could cause serious dificulties? (loader path
is the main place this gets exposed). Are there good reasons why it is
in fact not practical to change to using the new triplet (assuming
that we get on with it reasonably promptly)?
Thank you for reading this far, I look forward to your comments.
Wookey
--
Principal hats: Linaro, Debian, ARM
http://wookware.org/
