When using Rust on the x86 architecture, we are currently using the
unstable target.json feature to specify the compilation target. Rustc is
going to change how softfloat is specified in the target.json file on
x86, thus update generate_rust_target.rs to specify softfloat using the
new option.

Note that if you enable this parameter with a compiler that does not
recognize it, then that triggers a warning but it does not break the
build.

Cc: stable@vger.kernel.org # for 6.12.y
Link: https://github.com/rust-lang/rust/pull/136146
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
 scripts/generate_rust_target.rs | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/scripts/generate_rust_target.rs b/scripts/generate_rust_target.rs
index 0d00ac3723b5..4fd6b6ab3e32 100644
--- a/scripts/generate_rust_target.rs
+++ b/scripts/generate_rust_target.rs
@@ -165,6 +165,18 @@ fn has(&self, option: &str) -> bool {
         let option = "CONFIG_".to_owned() + option;
         self.0.contains_key(&option)
     }
+
+    /// Is the rustc version at least `major.minor.patch`?
+    fn rustc_version_atleast(&self, major: u32, minor: u32, patch: u32) -> bool {
+        let check_version = 100000 * major + 100 * minor + patch;
+        let actual_version = self
+            .0
+            .get("CONFIG_RUSTC_VERSION")
+            .unwrap()
+            .parse::<u32>()
+            .unwrap();
+        check_version <= actual_version
+    }
 }
 
 fn main() {
@@ -182,6 +194,9 @@ fn main() {
         }
     } else if cfg.has("X86_64") {
         ts.push("arch", "x86_64");
+        if cfg.rustc_version_atleast(1, 86, 0) {
+            ts.push("rustc-abi", "x86-softfloat");
+        }
         ts.push(
             "data-layout",
             "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128",
@@ -215,6 +230,9 @@ fn main() {
             panic!("32-bit x86 only works under UML");
         }
         ts.push("arch", "x86");
+        if cfg.rustc_version_atleast(1, 86, 0) {
+            ts.push("rustc-abi", "x86-softfloat");
+        }
         ts.push(
             "data-layout",
             "e-m:e-p:32:32-p270:32:32-p271:32:32-p272:64:64-i128:128-f64:32:64-f80:32-n8:16:32-S128",

---
base-commit: 40384c840ea1944d7c5a392e8975ed088ecf0b37
change-id: 20250203-rustc-1-86-x86-softfloat-0b973054c4bc

Best regards,
-- 
Alice Ryhl <aliceryhl@google.com>

On Mon, Feb 3, 2025 at 9:41 AM Alice Ryhl <aliceryhl@google.com> wrote:
>
> When using Rust on the x86 architecture, we are currently using the
> unstable target.json feature to specify the compilation target. Rustc is
> going to change how softfloat is specified in the target.json file on
> x86, thus update generate_rust_target.rs to specify softfloat using the
> new option.
>
> Note that if you enable this parameter with a compiler that does not
> recognize it, then that triggers a warning but it does not break the
> build.
>
> Cc: stable@vger.kernel.org # for 6.12.y
> Link: https://github.com/rust-lang/rust/pull/136146
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>

Applied to `rust-fixes` -- thanks everyone!

    [ For future reference, this solves the following error:

            RUSTC L rust/core.o
          error: Error loading target specification: target feature
          `soft-float` is incompatible with the ABI but gets enabled in
          target spec. Run `rustc --print target-list` for a list of
          built-in targets

      - Miguel ]

    [ Added 6.13.y too to Cc: stable tag and added reasoning to avoid
      over-backporting. - Miguel ]

Cheers,
Miguel

On Mon, Feb 3, 2025 at 9:41 AM Alice Ryhl <aliceryhl@google.com> wrote:
>
> When using Rust on the x86 architecture, we are currently using the
> unstable target.json feature to specify the compilation target. Rustc is
> going to change how softfloat is specified in the target.json file on
> x86, thus update generate_rust_target.rs to specify softfloat using the
> new option.
>
> Note that if you enable this parameter with a compiler that does not
> recognize it, then that triggers a warning but it does not break the
> build.
>
> Cc: stable@vger.kernel.org # for 6.12.y
> Link: https://github.com/rust-lang/rust/pull/136146
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>

x86: I will pick this up, but if x86 wants to do so, that would be
welcome -- in which case:

    Acked-by: Miguel Ojeda <ojeda@kernel.org>

and I would recommend updating the Cc stable tag to mention 6.13 and
the reason to avoid over-backports, e.g.

    Cc: <stable@vger.kernel.org> # Needed in 6.12.y and 6.13.y only
(Rust is pinned in older LTSs).

Cheers,
Miguel

First of all, thanks for cc'ing the x86 maintainers on this! I do think
it would be best if you take this through the rust tree though:

Acked-by: Dave Hansen <dave.hansen@linux.intel.com> # for x86

On Fri, Feb 7, 2025 at 12:08 AM Dave Hansen <dave.hansen@intel.com> wrote:
>
> First of all, thanks for cc'ing the x86 maintainers on this! I do think
> it would be best if you take this through the rust tree though:
>
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> # for x86

Great, thanks!

Cheers,
Miguel

On 2/6/25 10:51, Miguel Ojeda wrote:
> x86: I will pick this up, but if x86 wants to do so, that would be
> welcome -- in which case:
> 
>     Acked-by: Miguel Ojeda <ojeda@kernel.org>

Hey Miguel,

Are you saying you'd prefer that we pick this up on the x86 side? I'm
totally happy to do that, and it's obviously patching x86-specific
sections of the rust scripts.

If I'm understanding the ask.... Just curious though, what makes that
preferable? It's in a rust-specific file
(scripts/generate_rust_target.rs) and I'd guess that it'd be easier to
take it through the rust tree since it's more likely to collide with
stuff there and also be closer to the folks that can competently resolve
any merge problems.

On Thu, Feb 6, 2025 at 9:58 PM Dave Hansen <dave.hansen@intel.com> wrote:
>
> Are you saying you'd prefer that we pick this up on the x86 side? I'm
> totally happy to do that, and it's obviously patching x86-specific
> sections of the rust scripts.
>
> If I'm understanding the ask.... Just curious though, what makes that
> preferable? It's in a rust-specific file
> (scripts/generate_rust_target.rs) and I'd guess that it'd be easier to
> take it through the rust tree since it's more likely to collide with
> stuff there and also be closer to the folks that can competently resolve
> any merge problems.

I typically say something like that when I feel I may be overstepping
-- I don't want other subsystems to feel that they are being skipped.
For x86 I have so far taken things myself, since it was the first Rust
arch (so it was an exceptional case), but perhaps you wanted to start
handling things on your own etc.

I am happy either way, of course. Your Acked-by's would be very welcome!

Cheers,
Miguel