From: Yonghong Song <yonghong.song@linux.dev>
To: Nicolas Schier <nsc@kernel.org>,
linux-kbuild@vger.kernel.org, live-patching@vger.kernel.org
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
kernel-team@fb.com, Nathan Chancellor <nathan@kernel.org>,
Song Liu <song@kernel.org>
Subject: Re: [PATCH kbuild v2] kbuild: Reduce the number of compiler-generated suffixes for clang thin-lto build
Date: Sun, 15 Mar 2026 09:37:22 -0700 [thread overview]
Message-ID: <044bebc0-d996-4be3-9330-a64195c19a84@linux.dev> (raw)
In-Reply-To: <177332462174.82802.2344537821152391518.b4-ty@kernel.org>
On 3/12/26 7:12 AM, Nicolas Schier wrote:
> On Fri, 06 Mar 2026 21:02:50 -0800, Yonghong Song wrote:
>> The current clang thin-lto build often produces lots of symbols with
>> suffix. The following is a partial list of such function call symbols:
>> ...
>> ethnl_module_fw_flash_ntf.llvm.7631589765585346066
>> __nf_conntrack_alloc.llvm.6438426151906658917
>> tcp_can_early_drop.llvm.11937612064648250727
>> tcp_print_conntrack.llvm.11937612064648250727
>> ...
>>
>> [...]
> Note: Due to application of [1] to kbuild-next-unstable, I had to update the
> patch context.
>
> [1]: https://lore.kernel.org/linux-kbuild/20251028182822.3210436-1-xur@google.com/
>
>
>
> Applied to kbuild/kbuild-next.git (kbuild-next-unstable), thanks!
>
> [1/1] kbuild: Reduce the number of compiler-generated suffixes for clang thin-lto build
> https://git.kernel.org/kbuild/c/b7a7ce34
>
> Please look out for regression or issue reports or other follow up
> comments, as they may result in the patch/series getting dropped,
> reverted or modified (e.g. trailers). Patches applied to the
> kbuild-next-unstable branch are accepted pending wider testing in
> linux-next and any post-commit review; they will generally be moved
> to the kbuild-next branch in about a week if no issues are found.
Thanks, Nicolas,
I looked at the patch [1] and find that my patch needs some change.
The current change is
@@ -1047,6 +1047,7 @@ CC_FLAGS_LTO := -flto
else
CC_FLAGS_LTO := -flto=thin -fsplit-lto-unit
+KBUILD_LDFLAGS += $(call ld-option,--lto-whole-program-visibility
-mllvm -always-rename-promoted-locals=false)
endif
CC_FLAGS_LTO += -fvisibility=hidden Due to [1], the above change should
be @@ -1047,6 +1047,7 @@ CC_FLAGS_LTO := -flto
else
CC_FLAGS_LTO := -flto=thin -fsplit-lto-unit
+if CONFIG_LTO_CLANG_THIN
+KBUILD_LDFLAGS += $(call ld-option,--lto-whole-program-visibility
-mllvm -always-rename-promoted-locals=false)
+endif
endif
CC_FLAGS_LTO += -fvisibility=hidden
The reason likes below:
The patch [1] introduced CONFOG_LTO_CLANG_THIN_DIST and in Makefile, for the following change:
ifdef CONFIG_LTO_CLANG
-ifdef CONFIG_LTO_CLANG_THIN -CC_FLAGS_LTO := -flto=thin
-fsplit-lto-unit -else +ifdef CONFIG_LTO_CLANG_FULL CC_FLAGS_LTO := -flto
+else +CC_FLAGS_LTO := -flto=thin -fsplit-lto-unit endif
CC_FLAGS_LTO += -fvisibility=hidden
The else branch 'CC_FLAGS_LTO := -flto=thin -fsplit-lto-unit' will support both CONFIG_LTO_CLANG_THIN and CONFIG_LTO_CLANG_THIN_DIST.
My patch commit message mentioned that the new flag won't support
thinlto distributed mode yet. So The new ldflags
$(call ld-option,--lto-whole-program-visibility -mllvm
-always-rename-promoted-locals=false) needs under LTO_CLANG_THIN but not
LTO_CLANG_THIN_DIST. There will be some effort in llvm to support
distributed thin-lto as well for suffix reduction. But it may take a
little bit time as llvm needs some infrastructure change before
supporting distributed thin-lto. Thanks!
>
> Best regards,
next prev parent reply other threads:[~2026-03-15 16:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-07 5:02 [PATCH kbuild v2] kbuild: Reduce the number of compiler-generated suffixes for clang thin-lto build Yonghong Song
2026-03-10 3:14 ` Nathan Chancellor
2026-03-10 3:49 ` Josh Poimboeuf
2026-03-11 22:23 ` Song Liu
2026-03-12 14:12 ` Nicolas Schier
2026-03-15 16:37 ` Yonghong Song [this message]
2026-03-16 7:07 ` Nicolas Schier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=044bebc0-d996-4be3-9330-a64195c19a84@linux.dev \
--to=yonghong.song@linux.dev \
--cc=jpoimboe@kernel.org \
--cc=kernel-team@fb.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=nathan@kernel.org \
--cc=nsc@kernel.org \
--cc=song@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox