Message ID | 20240223-employee-pessimism-03ba0b58db6b@spud |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-78393-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:a81b:b0:108:e6aa:91d0 with SMTP id bq27csp588893dyb; Fri, 23 Feb 2024 05:39:52 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXE95Ml+sEVxuVADPYkYpdV6UujvU6kmXp+QLmVxYqKJuL/fGzAUbp8ZfsA6nMnAfetB3Vdggcydy3YT6pvjFM6lxusOw== X-Google-Smtp-Source: AGHT+IEBetM5O0VrACuYx7xEL6A8GDe2+Rdjn/+JZYOhy0IJv4wcae7LmZTlmOOIU7GGsTYoBHa/ X-Received: by 2002:a05:622a:1306:b0:42e:411d:ee50 with SMTP id v6-20020a05622a130600b0042e411dee50mr9020273qtk.15.1708695592162; Fri, 23 Feb 2024 05:39:52 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708695592; cv=pass; d=google.com; s=arc-20160816; b=dDKnc7B34156ehUTWNUbdfiNp9yDUIFZghgeCqJ0c8tlpWVjbYh1/0kffucPFrmNn6 Yo8y084UlhWvtxVfBGmWJmOMHe9/aI/0m6fC3zUX3KeUa5+TCCxC470g1bmzprtxJ6V+ P7iUz6xnyYFdo77gqejBizyxLsaOvrJXKUMivs8fBV4QZIwi/ctrxfh8qVQ9M8z0DhhF lUs7szfxuzEu1BEhQgTQrIwgYhdA8mEkYKkgjTm6QgXvPdG/e7s18yWwNLdRH+StnlfE zPYYkg+XEQSaHXdmPHerNXqEbpJqxquf0aDtnUoUB3uxzooyxY8lUxO6Znw3IhUnWyJF zY1A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=d9zTG9Q/D7hjqGdJH9bas9VTeOur6ufthRK5sGKsQCc=; fh=dCTP4Ymdp7PEyus72y/np7wEnm5YMONLCB550f4Y5pY=; b=bgcXhMhs/Cp96XWKf0+Isb5Ivk4R334ghLGJXUIcd32/e7NC+V0mXjpuLRdOVzl3wh nD0VixXtTRnP7az/jWw0Tcty8neCvNIAvHICV4wVVqiL8Bq95SeJkEUcivYMC0nfb0k8 /8mOOgHDw49o7+EzIQCO8hBiJ8XGSfwKjZa6lIu3NxvXD8CjeUaLsAs+Y0MWOfdTS78P rYFJ4C50qwpGr3ec0uk2TQ6pzRtAjj9TSrqL3cPh+KzxqvrbFjhd/RKnZ3jPz34S1hJR 0EfyeTAxaGFGOVtOC3BEkj9dBxcPfPoT/FRNW/dhW5cDVYkrLCPszym92dCwKlx6DHIB bOlw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=NAYoe9Wa; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-78393-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-78393-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id w12-20020a05622a134c00b0042e02fcfc98si13671553qtk.795.2024.02.23.05.39.52 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Feb 2024 05:39:52 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-78393-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=NAYoe9Wa; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-78393-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-78393-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id ECE8E1C221F2 for <ouuuleilei@gmail.com>; Fri, 23 Feb 2024 13:39:51 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id BEF9F81AD4; Fri, 23 Feb 2024 13:38:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NAYoe9Wa" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 35DB97FBA7; Fri, 23 Feb 2024 13:38:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708695521; cv=none; b=CiTAHvJXwgRBh+P9/JR4URTN6n1SVq8YAmd7ysEZeCiLZVmMvLqy1TUYmVWzo+3IryFV1t2hB+HIlyX0dOhZ2YWdlgj3QWzVnal+EGDlnWd3WPqPlS9mcibXPC3w6qDBuU0U0TYDGxOm1R5UJ9pmSfaKPivhK/NbqnKnutPS2Gc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708695521; c=relaxed/simple; bh=GBY3CxtFjRdlkWk0xQcPhghSUX/TMHc7PXVii3OW0UI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PggK4/WE18tkMe3xk0ZkF5I3vMO5DydSZxRioKKI5bcIGRpB4RbBmScVSFOKw0Ml17TgmBV8W1WqWBoCF96laPo/Xe3c5NC7LzRUt3fT2OO2V9qCksMlCXVoqD3pW+opZOdsFY4dq97G8JdrG1WGRqt5aZGBTX2MVQ8Ola0YGZQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NAYoe9Wa; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 84281C433C7; Fri, 23 Feb 2024 13:38:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1708695521; bh=GBY3CxtFjRdlkWk0xQcPhghSUX/TMHc7PXVii3OW0UI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NAYoe9WaOvWjK1nqOgnvCRLfNM1vZZ77ud9LwZ25q4toItC75bJj1HTjri6c2gXdA qx6gYl6UK3FaZPRWQtXRkeKeMNxLZH7BloLltp+gB9ahCt1OG+0ZTwxb3EoKpi6GYN Mbq4hQSa43Hf4YoY1B0DUu9QUvy3j4JJyAdd74AV3Avzt5xg6Ox4FylJRDHG1oSfts zB8IHxJFvZpDcgNweVSDpkC0wMuv3OWRL6SRzq91BNBWy7zk/+idBiurodqRLm6qSt lGDm6eVu3pt63byZpq3ks1rLII5B+W750e8gG1wICoaebGb7eaw3n4SUrkPrpfsh/r UHJujfNg9x3dg== From: Conor Dooley <conor@kernel.org> To: linux-riscv@lists.infradead.org Cc: conor@kernel.org, Conor Dooley <conor.dooley@microchip.com>, Miguel Ojeda <ojeda@kernel.org>, Alex Gaynor <alex.gaynor@gmail.com>, Wedson Almeida Filho <wedsonaf@gmail.com>, Boqun Feng <boqun.feng@gmail.com>, Gary Guo <gary@garyguo.net>, =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= <bjorn3_gh@protonmail.com>, Jonathan Corbet <corbet@lwn.net>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Nathan Chancellor <nathan@kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, Tom Rix <trix@redhat.com>, rust-for-linux@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev Subject: [PATCH v2 2/3] scripts: generate_rust_target: enable building on RISC-V Date: Fri, 23 Feb 2024 13:38:04 +0000 Message-ID: <20240223-employee-pessimism-03ba0b58db6b@spud> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240223-leverage-walmart-5424542cd8bd@spud> References: <20240223-leverage-walmart-5424542cd8bd@spud> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1601; i=conor.dooley@microchip.com; h=from:subject:message-id; bh=p3JdpTjlU4Gcdumuom76iCrubxUFIi9NJkWxSpqwhJ0=; b=owGbwMvMwCFWscWwfUFT0iXG02pJDKk35u/5lrFAdfnzD1GuIt8lz140CmXaqXr44cXs8KWGK R2WOsGHOkpZGMQ4GGTFFFkSb/e1SK3/47LDuectzBxWJpAhDFycAjCRPSsYGSan/60+PG/FqTAG kUlzFlW8U7p6xSjmJYeo5ZTlD5iZ9rkxMnwt/bL+85NpTZyR6SErzVtmXlqpyCW6YMKvR3qGn5M 3MbMDAA== X-Developer-Key: i=conor.dooley@microchip.com; a=openpgp; fpr=F9ECA03CF54F12CD01F1655722E2C55B37CF380C Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791697189036756498 X-GMAIL-MSGID: 1791697189036756498 |
Series |
RISC-V: enable rust
|
|
Commit Message
Conor Dooley
Feb. 23, 2024, 1:38 p.m. UTC
From: Miguel Ojeda <ojeda@kernel.org> Add the required bits from rust-for-linux to enable generating a RISC-V target for rust. The script, written by Miguel, was originally a config file contributed by Gary. Co-developed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Gary Guo <gary@garyguo.net> Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Conor Dooley <conor.dooley@microchip.com> --- scripts/generate_rust_target.rs | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
Comments
On Fri, Feb 23, 2024 at 2:38 PM Conor Dooley <conor@kernel.org> wrote: > > Add the required bits from rust-for-linux to enable generating a RISC-V > target for rust. The script, written by Miguel, was originally a > config file contributed by Gary. Thanks for this Connor! arm64 is sending these for 6.9: https://git.kernel.org/arm64/c/f82811e22b48 https://git.kernel.org/arm64/c/724a75ac9542 So it would be nice to see if it may be already possible to enable it via a builtin target + flags instead of the custom target, e.g. arm64 does: KBUILD_RUSTFLAGS += --target=aarch64-unknown-none -Ctarget-feature="-neon" and so on. If it does not work, it would be good to know what would be needed for RISC-V and put it into the unstable features / wanted features list for Rust. Either way, it is not a blocker (although you will need a rebase after arm64 lands to use the `target.json` in the right places). Cheers, Miguel
On Fri, Feb 23, 2024 at 03:39:47PM +0100, Miguel Ojeda wrote: > Conor Dooley <conor@kernel.org> wrote: > Thanks for this Connor! > arm64 is sending these for 6.9: > > https://git.kernel.org/arm64/c/f82811e22b48 > https://git.kernel.org/arm64/c/724a75ac9542 > > So it would be nice to see if it may be already possible to enable it > via a builtin target + flags instead of the custom target, e.g. arm64 > does: > > KBUILD_RUSTFLAGS += --target=aarch64-unknown-none -Ctarget-feature="-neon" > > and so on. > > If it does not work, it would be good to know what would be needed for > RISC-V and put it into the unstable features / wanted features list > for Rust. Sure, I'll take a look. > Either way, it is not a blocker (although you will need a rebase after > arm64 lands to use the `target.json` in the right places). Nah, I think that is silly. Either this goes in as-is, and there's fixup done by Linus, or the thing should be converted to match arm64, assuming that that is possible. Cheers, Conor.
On Tue, Feb 27, 2024 at 11:17 AM Conor Dooley <conor.dooley@microchip.com> wrote: > > Sure, I'll take a look. Thanks! > Nah, I think that is silly. Either this goes in as-is, and there's > fixup done by Linus, or the thing should be converted to match arm64, > assuming that that is possible. Ah, so you are going for 6.9 too? I can give the series a try on my side in that case. When do you plan to apply them? Cheers, Miguel
On Tue, Feb 27, 2024 at 11:46:42AM +0100, Miguel Ojeda wrote: > On Tue, Feb 27, 2024 at 11:17 AM Conor Dooley > <conor.dooley@microchip.com> wrote: > > > > Sure, I'll take a look. > > Thanks! > > > Nah, I think that is silly. Either this goes in as-is, and there's > > fixup done by Linus, or the thing should be converted to match arm64, > > assuming that that is possible. > > Ah, so you are going for 6.9 too? I can give the series a try on my > side in that case. When do you plan to apply them? If they're to be applied, it would be Palmer, not I. And if history is any guide, it could be into the merge window. My point though was more that either this was acceptable for v6.9 or would be v6.10 material with the same mechanism as arm64. Rebasing after v6.9-rc1 but not adapting to that way of doing things is what seemed silly to me, since if a resend is required then the other improvements should be carried out at the same time. Cheers, Conor.
On Tue, Feb 27, 2024 at 12:05 PM Conor Dooley <conor.dooley@microchip.com> wrote: > > My point though was more > that either this was acceptable for v6.9 or would be v6.10 material > with the same mechanism as arm64. Rebasing after v6.9-rc1 but not > adapting to that way of doing things is what seemed silly to me, since > if a resend is required then the other improvements should be carried > out at the same time. If avoiding the `target.json` is possible, definitely. I didn't want to assume it is, though -- e.g. the native integer widths you have is 64 but the built-in targets use 32:64 (perhaps there is a way to tweak it with an LLVM param via `-Cllvm-args`, but I don't see any obvious way from a quick look; `opt` does have it, though). (That is why we supported `target.json`, since it gives the most freedom in the beginning.) Cheers, Miguel
On Tue, Feb 27, 2024 at 01:12:51PM +0100, Miguel Ojeda wrote: > On Tue, Feb 27, 2024 at 12:05 PM Conor Dooley > <conor.dooley@microchip.com> wrote: > > > > My point though was more > > that either this was acceptable for v6.9 or would be v6.10 material > > with the same mechanism as arm64. Rebasing after v6.9-rc1 but not > > adapting to that way of doing things is what seemed silly to me, since > > if a resend is required then the other improvements should be carried > > out at the same time. > > If avoiding the `target.json` is possible, definitely. > > I didn't want to assume it is, though -- e.g. the native integer > widths you have is 64 but the built-in targets use 32:64 (perhaps > there is a way to tweak it with an LLVM param via `-Cllvm-args`, but I > don't see any obvious way from a quick look; `opt` does have it, > though). Looking closer at those targets, all of them enable compressed instructors, but we support hardware that does not support them. I think that means we are stuck with the custom targets. I could badger Palmer to pick this up tomorrow, provided you're okay with the gist of this series. Cheers, Conor.
On Tue, Feb 27, 2024 at 1:37 PM Conor Dooley <conor.dooley@microchip.com> wrote: > > Looking closer at those targets, all of them enable compressed > instructors, but we support hardware that does not support them. > I think that means we are stuck with the custom targets. Did you try `-Ctarget-feature=-c`? i.e. as far as I know, you can disable target features even if they are enabled from the built-in. It seems to work from a quick try (in userspace), e.g. 0000000000000000 <f>: 0: 9b 05 05 00 sext.w a1, a0 4: 13 05 a0 02 li a0, 0x2a 8: 63 84 05 00 beqz a1, 0x10 <f+0x10> c: 13 05 b0 07 li a0, 0x7b 10: 67 80 00 00 ret vs. 0000000000000000 <f>: 0: 9b 05 05 00 sext.w a1, a0 4: 13 05 a0 02 li a0, 0x2a 8: 99 c1 beqz a1, 0xe <f+0xe> a: 13 05 b0 07 li a0, 0x7b e: 82 80 ret Cheers, Miguel
On Tue, Feb 27, 2024 at 03:47:29PM +0100, Miguel Ojeda wrote: > Did you try `-Ctarget-feature=-c`? i.e. as far as I know, you can > disable target features even if they are enabled from the built-in. No, I didn't actually try anything. Between trying to test the kcfi stuff on arm64 and the other work I was doing today I did not have a chance to actually play with that yet. It comes down to you though I suppose - would you rather have generate_rust_target enable the compressed instructions depending on the config option or have the Makefile disable it if compressed instructions are not enabled and use a builtin target?
On Tue, Feb 27, 2024 at 6:48 PM Conor Dooley <conor@kernel.org> wrote: > > No, I didn't actually try anything. Between trying to test the kcfi > stuff on arm64 and the other work I was doing today I did not have a > chance to actually play with that yet. Apologies, I didn't mean it that way -- I was just wondering if it didn't work. No rush on my side (in fact, I thought this was for 6.10 anyway). > It comes down to you though I > suppose - would you rather have generate_rust_target enable the > compressed instructions depending on the config option or have the > Makefile disable it if compressed instructions are not enabled and use > a builtin target? So the custom target support is there for flexibility purposes: we were told is that since the target spec is too tied to LLVM, it is unlikely to get stabilized (at least as it is), and thus they preferred that we ask for whatever flags in `rustc` would be needed to tweak things in an existing builtin target (or add new built-in targets if needed). Thus, when a new architecture is added, the question is whether one can already use the flags approach or not. For instance, to disable the compressed instructions, from what I can tell, the flag I mentioned seems to work, so that is fine. However, for something like tweaking the data layout for `n64` instead of `n32:64`, I am not aware of a way to do so via a flag (but I see newer LLVM uses `n32:64`, so that may be the better one anyway: https://godbolt.org/z/Eh4cfdeMr). So it all depends on whether you are happy with what the flags approach already give you. I hope that clarifies a bit! Cheers, Miguel
On Tue, Feb 27, 2024 at 07:11:17PM +0100, Miguel Ojeda wrote: > On Tue, Feb 27, 2024 at 6:48 PM Conor Dooley <conor@kernel.org> wrote: > For instance, to disable the compressed instructions, from what I can > tell, the flag I mentioned seems to work, so that is fine. To me, using flags is a good fit given that's what we do elsewhere, and there won't be a mix of stuff that is done conditionally in a script and conditionally in a Makefile. > However, > for something like tweaking the data layout for `n64` instead of > `n32:64`, I am not aware of a way to do so via a flag (but I see newer > LLVM uses `n32:64`, so that may be the better one anyway: > https://godbolt.org/z/Eh4cfdeMr). Yeah, I had looked at the blame for the targets earlier today and noticed that it had been changed. Sadly rustc's commit is lacking any justification whatsoever for the change, so I was not going to really comment on that until I had looked. > So it all depends on whether you are happy with what the flags > approach already give you. > > I hope that clarifies a bit! Ye, thanks. I'll give it a go when I have a bit of time this week.
diff --git a/scripts/generate_rust_target.rs b/scripts/generate_rust_target.rs index 416c6b89e806..942ddca57ee4 100644 --- a/scripts/generate_rust_target.rs +++ b/scripts/generate_rust_target.rs @@ -171,6 +171,22 @@ fn main() { ts.push("llvm-target", "loongarch64-linux-gnusf"); ts.push("llvm-abiname", "lp64s"); ts.push("target-pointer-width", "64"); + } else if cfg.has("RISCV") { + if cfg.has("64BIT") { + ts.push("arch", "riscv64"); + ts.push("data-layout", "e-m:e-p:64:64-i64:64-i128:128-n64-S128"); + ts.push("llvm-target", "riscv64-linux-gnu"); + ts.push("target-pointer-width", "64"); + } else { + panic!("32-bit RISC-V is an unsupported architecture"); + } + ts.push("code-model", "medium"); + ts.push("disable-redzone", true); + let mut features = "+m,+a".to_string(); + if cfg.has("RISCV_ISA_C") { + features += ",+c"; + } + ts.push("features", features); } else { panic!("Unsupported architecture"); }