Re: next/master bisection: baseline.login on rk3288-rock2-square
From: Ard Biesheuvel <ardb@kernel.org>
Date: 2021-02-05 08:23:12
Also in:
lkml
On Thu, 4 Feb 2021 at 22:31, Guillaume Tucker [off-list ref] wrote:
On 04/02/2021 18:23, Nick Desaulniers wrote:quoted
On Thu, Feb 4, 2021 at 10:12 AM Nathan Chancellor [off-list ref] wrote:quoted
On Thu, Feb 04, 2021 at 10:06:08AM -0800, 'Nick Desaulniers' via Clang Built Linux wrote:quoted
On Thu, Feb 4, 2021 at 8:02 AM Ard Biesheuvel [off-list ref] wrote:quoted
On Thu, 4 Feb 2021 at 16:53, Guillaume Tucker [off-list ref] wrote:quoted
On 04/02/2021 15:42, Ard Biesheuvel wrote:quoted
On Thu, 4 Feb 2021 at 12:32, Guillaume Tucker [off-list ref] wrote:quoted
Essentially: make -j18 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LLVM=1 CC="ccache clang" zImageThis command should link with BFD (and assemble with GAS; it's only using clang as the compiler.I think you missed the 'LLVM=1' before CC="ccache clang". That should use all of the LLVM utilities minus the integrated assembler while wrapping clang with ccache.You're right, I missed `LLVM=1`. Adding `LD=ld.bfd` I think should permit fallback to BFD.That was close, except we're cross-compiling with GCC for arm. So I've now built a plain next-20210203 (without Ard's fix) using this command line: make LD=arm-linux-gnueabihf-ld.bfd -j18 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LLVM=1 CC="ccache clang" zImage I'm using a modified Docker image gtucker/kernelci-build-clang-11 with the very latest LLVM 11 and gcc-8-arm-linux-gnueabihf packages added to be able to use the GNU linker. BTW I guess we should enable this kind of hybrid build setup on kernelci.org as well. Full build log + kernel binaries can be found here: https://storage.staging.kernelci.org/gtucker/next-20210203-ard-fix/v5.10-rc4-24722-g58b6c0e507b7-gtucker_single-staging-41/arm/multi_v7_defconfig/clang-11/ And this booted fine, which confirms it's really down to how ld.lld puts together the kernel image. Does it actually solve the debate whether this is an issue to fix in the assembly code or at link time? Full test job details for the record: https://lava.collabora.co.uk/scheduler/job/3176004
So the issue appears to be in the way the linker generates the _kernel_bss_size symbol, which obviously has an impact, given that the queued fix takes it into account in the cache_clean operation. On GNU ld, I see 479: 00065e14 0 NOTYPE GLOBAL DEFAULT ABS _kernel_bss_size whereas n LLVM ld.lld, I see 433: c1c86e98 0 NOTYPE GLOBAL DEFAULT ABS _kernel_bss_size and adding this value may cause the cache clean to operate on unmapped addresses, or cause the addition to wrap and not perform a cache clean at all. AFAICT, this also breaks the appended DTB case in LLVM, so this needs a separate fix in any case. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel