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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.