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/
signature.asc
Description: Digital signature
_______________________________________________ cross-distro mailing list cross-distro@lists.linaro.org https://lists.linaro.org/mailman/listinfo/cross-distro
