From: Nathan Chancellor <nathan@kernel.org>
To: Yonghong Song <yonghong.song@linux.dev>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
linux-kbuild@vger.kernel.org, live-patching@vger.kernel.org,
kernel-team@fb.com, Nicolas Schier <nsc@kernel.org>,
Song Liu <song@kernel.org>
Subject: Re: [PATCH kbuild] kbuild: Allow to reduce the number of suffixes for clang thin-lto build
Date: Fri, 6 Mar 2026 15:45:22 -0700 [thread overview]
Message-ID: <20260306224522.GA2746259@ax162> (raw)
In-Reply-To: <f0c037e6-d498-41c3-8d71-0597a2e1d68d@linux.dev>
On Fri, Mar 06, 2026 at 02:12:44PM -0800, Yonghong Song wrote:
> So you mean we do not need a new config. Should just check clang and
> clang versionn like below?
>
> diff --git a/Makefile b/Makefile
> index e944c6e71e81..9bd3990024c5 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1034,6 +1034,11 @@ endif
> ifdef CONFIG_LTO_CLANG
> ifdef CONFIG_LTO_CLANG_THIN
> CC_FLAGS_LTO := -flto=thin -fsplit-lto-unit
> +ifdef CONFIG_CC_IS_CLANG
> +ifeq ($(shell test $(CONFIG_CLANG_VERSION) -ge 230000; echo $$?),0)
This is the same as
ifeq ($(call clang-min-version,230000),y)
That being said, could we not just do a dynamic check so that it always
works when these flags are supported?
> +KBUILD_LDFLAGS += --lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false
KBUILD_LDFLAGS += $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
> +endif
> +endif
> else
> CC_FLAGS_LTO := -flto
> endif
>
> I think this should work. In rare case, renaming the function should
> solve the problem.
I agree with Josh that having this be the default behavior with the
workarounds that we have available to us to avoid problems from it is
worth it. Thanks for chasing this after the discussions at LPC.
Cheers,
Nathan
next prev parent reply other threads:[~2026-03-06 22:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-06 3:43 [PATCH kbuild] kbuild: Allow to reduce the number of suffixes for clang thin-lto build Yonghong Song
2026-03-06 18:32 ` Josh Poimboeuf
2026-03-06 19:40 ` Yonghong Song
2026-03-06 20:54 ` Josh Poimboeuf
2026-03-06 20:57 ` Josh Poimboeuf
2026-03-06 22:12 ` Yonghong Song
2026-03-06 22:45 ` Nathan Chancellor [this message]
2026-03-07 5:14 ` Yonghong Song
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=20260306224522.GA2746259@ax162 \
--to=nathan@kernel.org \
--cc=jpoimboe@kernel.org \
--cc=kernel-team@fb.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=nsc@kernel.org \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/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