Re: next/master bisection: baseline.login on rk3288-rock2-square
From: Ard Biesheuvel <ardb@kernel.org>
Date: 2021-02-06 13:13:56
Also in:
lkml
On Sat, 6 Feb 2021 at 14:10, Guillaume Tucker [off-list ref] wrote:
On 05/02/2021 12:05, Ard Biesheuvel wrote:quoted
On Fri, 5 Feb 2021 at 09:21, Ard Biesheuvel [off-list ref] wrote:quoted
On Thu, 4 Feb 2021 at 22:31, Guillaume Tucker [off-list ref] wrote:quoted
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/3176004So 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.That's right, Clang builds are only enabled on linux-next and mainline at the moment. We could enable it on any other branch where it makes sense. How about just the main defconfig for arm, arm64 and x86_64 on your ardb/for-kernelci branch?
Yes, please.
For now I've run another set of builds with clang-11 and got the following test results with your branch on staging: https://staging.kernelci.org/test/job/ardb/branch/for-kernelci/kernel/v5.11-rc6-146-g923ca344043a/plan/baseline/ which are all passing. I'll reply to the thread with your patch to confirm.
Excellent, thanks a lot. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel