[PATCH] arm64: Make CPU_BIG_ENDIAN depend on !LD_IS_LLD

[Peter Smith]

> -----Original Message-----
> From: Arnd Bergmann <arnd at kernel.org>
> Sent: 02 February 2021 20:44
> To: Nathan Chancellor <nathan at kernel.org>
> Cc: Catalin Marinas <Catalin.Marinas at arm.com>; Will Deacon
> <will at kernel.org>; Linux ARM <linux-arm-kernel at lists.infradead.org>; linux-
> kernel at vger.kernel.org; Nick Desaulniers <ndesaulniers at google.com>;
> clang-built-linux <clang-built-linux at googlegroups.com>; Arnd Bergmann
> <arnd at arndb.de>; Peter Smith <Peter.Smith at arm.com>
> Subject: Re: [PATCH] arm64: Make CPU_BIG_ENDIAN depend on !LD_IS_LLD
> 
> On Tue, Feb 2, 2021 at 8:51 PM Nathan Chancellor <nathan at kernel.org>
> wrote:
> > On Tue, Feb 02, 2021 at 09:04:34AM +0100, Arnd Bergmann wrote:
> > > On Tue, Feb 2, 2021 at 3:25 AM Nathan Chancellor <nathan at kernel.org>
> wrote:
> > > >
> > > > Similar to commit 28187dc8ebd9 ("ARM: 9025/1: Kconfig:
> > > > CPU_BIG_ENDIAN depends on !LD_IS_LLD"), ld.lld does not support
> > > > aarch64 big endian, leading to the following build error when
> > > > CONFIG_CPU_BIG_ENDIAN is
> > > > selected:
> > > >
> > > > ld.lld: error: unknown emulation: aarch64linuxb
> > >
> > > While this is the original error message I reported, I think it
> > > would be better to explain that lld actually does support linking
> > > big-endian kernels but they don't boot, for unknown reasons.
> >
> > That statement seems to contradict what Peter Smith says:
> >
> > https://github.com/ClangBuiltLinux/linux/issues/1288#issuecomment-7706
> > 93582
> >
> > https://reviews.llvm.org/D58655#1410282
> 
> Right, adding Peter to Cc for clarification. Peter, what I can tell from
> experiments is that lld behaves just you describe it should, and (aside from
> the command like flag handling) like ld.bfd, so I'm not sure if there are any
> known deficiencies or just minor bugs when dealing with the kernel.
> 

If an emulation (-m) is present then current LLD maps all known Arm and AArch emulations to little endian
https://github.com/llvm/llvm-project/blob/main/lld/ELF/Driver.cpp#L147 

In this case we'll get an error message with a big-endian object.
ld.lld: error: be.o is incompatible with aarch64linux

If there are no emulations present then LLD will auto-detect big-endian from the first object file.
https://github.com/llvm/llvm-project/blob/main/lld/ELF/Driver.cpp#L1467

This will switch the generic LLD write functions to write big-endian. This will mean that any write to instructions will need to use explicit write32le and any data relocations will need to use write32/write64 as appropriate and not use the explicit le versions. The relocations for instructions look to be using explicit le writes as we'd want them to. I've spotted at least one case of using write64le for what looks like data
https://github.com/llvm/llvm-project/blob/main/lld/ELF/Arch/AArch64.cpp#L198

I've not know anyone try LLD on big-endian before so there are no known deficiencies. I expect that without an active search and tests there will be some problems. I think every write will need looking at, if it is to instructions it needs to explicitly use le, if to data (that could be either little or big endian) it must not force little endian.

Peter


> FWIW, I have now built a big-endian musl C library and a helloworld binary,
> which I linked with ld.lld and successfully tested using qemu-aarch64_be-
> static
> 
>       Arnd
> 
> > > I can send a patch to address the build error and mark big-endian as
> > > "depends on !LD_IS_LLD || COMPILE_TEST" to reflect that and help
> > > with randconfig testing.
> >
> > I have no strong opinion on handling this though.