Building the Linux kernel with Clang and LLVM
 help / color / mirror / Atom feed
From: David Gow <davidgow@google.com>
To: "Thomas Weißschuh" <linux@weissschuh.net>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Richard Weinberger" <richard@nod.at>,
	"Johannes Berg" <johannes@sipsolutions.net>,
	"Roberto Sassu" <roberto.sassu@huaweicloud.com>,
	"Vincenzo Palazzo" <vincenzopalazzodev@gmail.com>
Cc: "David Gow" <davidgow@google.com>,
	x86@kernel.org, "Nathan Chancellor" <nathan@kernel.org>,
	"Nick Desaulniers" <ndesaulniers@google.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <benno.lossin@proton.me>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	rust-for-linux@vger.kernel.org, llvm@lists.linux.dev,
	linux-um@lists.infradead.org,
	"Anton Ivanov" <anton.ivanov@cambridgegreys.com>,
	kunit-dev@googlegroups.com, linux-kernel@vger.kernel.org
Subject: [PATCH] arch: um: Pass the correct Rust target and options with gcc
Date: Mon, 10 Feb 2025 18:53:51 +0800	[thread overview]
Message-ID: <20250210105353.2238769-2-davidgow@google.com> (raw)

In order to work around some issues with disabling SSE on older versions
of gcc (compilation would fail upon seeing a function declaration
containing a float, even if it was never called or defined), the
corresponding CFLAGS and RUSTFLAGS were only set when using clang.

However, this led to two problems:
- Newer gcc versions also wouldn't get the correct flags, despite not
  having the bug.
- The RUSTFLAGS for setting the rust target definition were not set,
  despite being unrelated. This works by chance for x86_64, as the
  built-in default target is close enough, but not for 32-bit x86.

Move the target definition outside the conditional block, and update the
condition to take into account the gcc version.

Fixes: a3046a618a28 ("um: Only disable SSE on clang to work around old GCC bugs")
Signed-off-by: David Gow <davidgow@google.com>
---

When combined with Thomas' patch [1], this gets Rust/UML building
correctly with gcc. (Indeed, Thomas' patch works fine by itself for the
64-bit case, and the 32-bit build is broken anyway due to the Rust block
driver not supporting 64-bit atomics on 32-bit systems.)

Given the other patches will probably go in via the rust-for-linux tree,
I'd be happy for this to do so as well (given it mostly affects Rust),
but it's not a disaster if they go in independently: there shouldn't be
any merge conflicts, and they work independently.

Note also that I don't actually have an old enough gcc nearby, so
haven't actually tested this on gcc < 11. So please let me know if this
breaks for you.

Cheers,
-- David

[1]: https://lore.kernel.org/rust-for-linux/20250208-rust-kunit-v1-1-94a026be6d72@weissschuh.net/

---
 arch/x86/Makefile.um | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Makefile.um b/arch/x86/Makefile.um
index a46b1397ad01..c86cbd9cbba3 100644
--- a/arch/x86/Makefile.um
+++ b/arch/x86/Makefile.um
@@ -7,12 +7,13 @@ core-y += arch/x86/crypto/
 # GCC versions < 11. See:
 # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99652
 #
-ifeq ($(CONFIG_CC_IS_CLANG),y)
-KBUILD_CFLAGS += -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx
-KBUILD_RUSTFLAGS += --target=$(objtree)/scripts/target.json
+ifeq ($(call gcc-min-version, 110000)$(CONFIG_CC_IS_CLANG),y)
+KBUILD_CFLAGS +=  -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx
 KBUILD_RUSTFLAGS += -Ctarget-feature=-sse,-sse2,-sse3,-ssse3,-sse4.1,-sse4.2,-avx,-avx2
 endif
 
+KBUILD_RUSTFLAGS += --target=$(objtree)/scripts/target.json
+
 ifeq ($(CONFIG_X86_32),y)
 START := 0x8048000
 
-- 
2.48.1.502.g6dc24dfdaf-goog


                 reply	other threads:[~2025-02-10 10:54 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20250210105353.2238769-2-davidgow@google.com \
    --to=davidgow@google.com \
    --cc=a.hindborg@kernel.org \
    --cc=aliceryhl@google.com \
    --cc=anton.ivanov@cambridgegreys.com \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=gary@garyguo.net \
    --cc=johannes@sipsolutions.net \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-um@lists.infradead.org \
    --cc=linux@weissschuh.net \
    --cc=llvm@lists.linux.dev \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=ojeda@kernel.org \
    --cc=richard@nod.at \
    --cc=roberto.sassu@huaweicloud.com \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    --cc=vincenzopalazzodev@gmail.com \
    --cc=x86@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