I wish that we don’t just propose things as we can. It’s very difficult to find aarch64_be-ilp32 results in a search engine. Supporting big-endian for aarch64 ilp32 will incur a small but non-negligible dispatch cost to regular aarch64 little-endian users, so I encourage that we think harder whether such a configuration is necessary.
We are working on big-endian support for Arm (AArch32) in LLD. Hopefully will have some initial patches within a week or so. We have some working BE32 (legacy support), which we can use to build the modern BE8 support which requires the linker to endian reverse instructions.
Arm is unlikely to work on AArch64 ILP32 support itself. There is Beta support in the ABI abi-aa/aaelf64.rst at main · ARM-software/abi-aa · GitHub for the relocations. There have been builds of GCC that support this . However due to the lack of support, and unlikely future support, in upstream linux; clang/llvm/lld ILP32 support isn’t a priority for Arm.
As MaskRay says supporting ILP32 in LLD is likely not too difficult, but it needs to justify its inclusion in upstream as it has a non-neglible maintenance overhead. Ideally it would need good clang/llvm support with active upstream users. The closest I’ve seen is in ⚙ D94143 [AArch64] Add support for the GNU ILP32 ABI would you be able to elaborate on the use case.
Sorry for replying too late. Thanks for all advice.
I am working on embedded projects, and I try to use lld to replace ld.bfd linker.
I have done the jobs to add new target aarch64elf32b, aarch64linux32b in lld to support aarch64_be-ilp32, and it looks like working properly.