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