All of lore.kernel.org
 help / color / mirror / Atom feed
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,


  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.