[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPhsuW5urLfhiCt2dhorVcZoMxZRady362vbfK78A7Z+3id2ew@mail.gmail.com>
Date: Wed, 29 Jan 2025 15:04:56 -0800
From: Song Liu <song@...nel.org>
To: Yonghong Song <yonghong.song@...ux.dev>, Masahiro Yamada <masahiroy@...nel.org>
Cc: Nathan Chancellor <nathan@...nel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: clang thin-lto not working for aarch64 for v6.13
Hi Masahiro and Nathan,
On Mon, Jan 27, 2025 at 9:50 AM Song Liu <song@...nel.org> wrote:
>
> On Sun, Jan 26, 2025 at 7:48 PM Yonghong Song <yonghong.song@...ux.dev> wrote:
> >
> > Hi, Masahiro,
> >
> > We are trying 6.13 kernel and found that for aarch64 thinlto not
> > working. For example, for kernel/bpf/syscall.o, the compilation flags
> > from .syscall.o.cmd are savedcmd_kernel/bpf/syscall.o := clang
> > -Wp,-MMD,kernel/bpf/.syscall.o.d ... -D__KBUILD_MODNAME=kmod_syscall -c
> > -o kernel/bpf/syscall.o kernel/bpf/syscall.c ; ld.lld -EL -maarch64elf
> > -z norelro -mllvm -import-instr-limit=5 -z noexecstack -r -o
> > kernel/bpf/.tmp_syscall.o kernel/bpf/syscall.o; mv
> > kernel/bpf/.tmp_syscall.o kernel/bpf/syscall.o I did some bisecting and
> > found the issue is due to ``` commit
> > bede169618c68379e1be7ace14e8ac85b964a9ec Author: Masahiro Yamada
> > <masahiroy@...nel.org> Date: Thu Nov 14 08:45:22 2024 +0900 kbuild:
> > enable objtool for *.mod.o and additional kernel objects ``` In the
> > above, for thinlto, we should not do ld.lld as compiler needs IR to do
> > cross-file inlining. Searching the internet, I found that the issue has
> > been reported e.g. in
> > https://patchwork.kernel.org/project/linux-kbuild/patch/20241113234526.402738-3-masahiroy@kernel.org/
>
> It appears the fix suggested by Nathan is already squashed with the
> commit before being merged upstream. However, this causes another
> issue. As Yonghong stated, after upstream commit
> bede169618c68379e1be7ace14e8ac85b964a9ec, the linker runs on
> individual .o file, which defeats the benefit of LTO.
It appears we still have this issue in the latest upstream kernel. Reverting
bede169618c68379e1be7ace14e8ac85b964a9ec fixes the issue. But I
am not sure whether we can do that without also reverting
1b466b29a3bf02ed95f28682a975f41ae47bce7d.
Could you please share your suggestions on this?
Thanks,
Song
> IIUC, the proper behavior is to do "cmd_ld_single" only for "is-single-obj-m"
> case. However, after bede169618c68379e1be7ace14e8ac85b964a9ec,
> the "is-single-obj-m" check is removed. I am not quite sure what is the
> proper fix for this.
[...]
Powered by blists - more mailing lists