On Fri, 5 Feb 2021 at 09:21, Ard Biesheuvel <a...@kernel.org> wrote: > > On Thu, 4 Feb 2021 at 22:31, Guillaume Tucker > <guillaume.tuc...@collabora.com> wrote: > > > > On 04/02/2021 18:23, Nick Desaulniers wrote: > > > On Thu, Feb 4, 2021 at 10:12 AM Nathan Chancellor <nat...@kernel.org> > > > wrote: > > >> > > >> On Thu, Feb 04, 2021 at 10:06:08AM -0800, 'Nick Desaulniers' via Clang > > >> Built Linux wrote: > > >>> On Thu, Feb 4, 2021 at 8:02 AM Ard Biesheuvel <a...@kernel.org> wrote: > > >>>> > > >>>> On Thu, 4 Feb 2021 at 16:53, Guillaume Tucker > > >>>> <guillaume.tuc...@collabora.com> wrote: > > >>>>> > > >>>>> On 04/02/2021 15:42, Ard Biesheuvel wrote: > > >>>>>> On Thu, 4 Feb 2021 at 12:32, Guillaume Tucker > > >>>>>> <guillaume.tuc...@collabora.com> wrote: > > >>>>>>> > > >>>>>>> Essentially: > > >>>>>>> > > >>>>>>> make -j18 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LLVM=1 > > >>>>>>> CC="ccache clang" zImage > > >>> > > >>> This 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.
I pushed a combined branch of torvalds/master, rmk/fixes (still containing my 9052/1 fix) and this patch to my for-kernelci branch https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/ Guillaume, It seems there is no Clang-11 coverage there, right? Mind giving this branch a spin? If this fixes the regressions, we can get these queued up. Thanks, Ard.