ILP32 loader path and triplet
ILP32 is an ABI to run on ARM v8 64-bit-only cores. Thus it has the same basic properties as aarch32 or armv7 code (ints, long and pointers are 32bit), but only uses the armv8 A64 instruction set. It is exactly the same concept as x32 on the x86 architecture (but is interesting for somewhat different reasons).
There has been some discussion over the last year about the degree to which this was actually neeed/useful in the real world, and it seems that enough people care that the development work will be finished and it will be upstreamed. Binutils and gcc already have basic support upstream, a kernel ABI has finally been agreed, and thus the glibc implementation can now be finished.
So, whilst distros (certainly Debian, but I presume others) remain entirely uninterested in this as a supported architecture, some people do want to be able to build it, and that means we should agree the triplet and loader path to be used so it's not gratuitously different between distros.
This page has been up for a year or so giving current status, rationale and sugested names: https://wiki.linaro.org/Platform/arm64-ilp32
It was brought up in the cross-distro session at Linaro Connect in November 2015 and no-one seemed to object violently to what is there.
So, before people start actually building this for real (beyond OE) I'd like to confirm that everyone is happy to use these, which are essentially just following on from the existing aarch64 and aaarch64_be names, and ensuring that the loader path is unique.
GNU name ('triplet'): aarch64_ilp32-linux-gnu
Loader path: /lib/ld-linux-aarch64_ilp32.so.1
And Big endian versions: (quite which crazies are going to build ilp32-big-endian I don't know, but lets define them whilst we are here :-)
GNU name ('triplet'): aarch64_be_ilp32-linux-gnu
Loader path: /lib/ld-linux-aarch64_be_ilp32.so.1
Do we have a shed which is already adequately painted, or would people like to argue for something different?
I would like to send in a dpkg patch soon so that it's possible to build this stuff with debian tools, and there will no doubt be further discussion about actually building ILP32 toolchains and packages at Linaro connect in March. I'm hoping this naming isn't controversial.
Aside: Oh and if you didn't know (I didn't until I looked it up for this). ILP32 just comes from "Integer, Long, and Pointer 32"
Wookey