Hi Wookey,
A quick (top post!) reply...
1). Thanks for sending this, and for initiating the discussion.
2). We are discussing within Red Hat. I personally like your proposal.
We will followup - I suggest a sync at Connect, since it's close?
3). Red Hat has absolutely NO INTEREST in shipping or supporting ILP32
and explicitly has plan to NEVER ship any ILP32 distribution. I
am calling this out since I don't want anyone to get the wrong
idea and think we are in any way supportive of ILP32 in server.
Thanks for your usual attention to detail!
Jon.
On 02/01/2017 06:50 PM, Wookey wrote:
> 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
>
>
>
> _______________________________________________
> cross-distro mailing list
> cross-distro@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/cross-distro
>
_______________________________________________
cross-distro mailing list
cross-distro@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/cross-distro
