Received-SPF: pass (google.com: domain of linux-kernel+bounces-40640-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20230307102441.94417-1-conor.dooley@microchip.com>
 <20230608-dispatch-sneer-aa09bd7b2eb8@wendy> <CANiq72nnph7LS1fLRtHz8NJ91PWXPaUnm0EuoV3wrbvK398AnA@mail.gmail.com>
 <20230608-spiritism-gonad-5f5aff4c3a24@wendy> <20240117-swiftly-parasail-618d62972d6e@spud>
 <CANiq72mVKCOAuK4Qe+8AHmpkFwyJsVfx8AqB7ccGi3DYpSSWcw@mail.gmail.com>
 <20240118-implode-delirium-eefdd86e170e@spud> <CANiq72nx1s_nyvPW86jL7eiOxROr18LfOJqNtw8L42CP+gkhRg@mail.gmail.com>
 <20240125-bucked-payroll-47f82077b262@wendy> <CANiq72k7n0aZrifRRU08N8qLkNe+2EZwijZy5sM7M56n2xYHgQ@mail.gmail.com>
 <20240125-lazy-thrower-744aacc6632a@wendy>
In-Reply-To: <20240125-lazy-thrower-744aacc6632a@wendy>
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date: Fri, 26 Jan 2024 22:00:02 +0100
Message-ID: <CANiq72kb+_utZrYHtoKZQtQazikmkjpVUHpTBcaANizduMF5QQ@mail.gmail.com>
Subject: Re: [PATCH v1 0/2] RISC-V: enable rust
To: Conor Dooley <conor.dooley@microchip.com>
Cc: Conor Dooley <conor@kernel.org>, linux-riscv@lists.infradead.org, 
	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, 
	Matthew Maurer <mmaurer@google.com>, Ramon de C Valle <rcvalle@google.com>, 
	Sami Tolvanen <samitolvanen@google.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 25, 2024 at 2:46=E2=80=AFPM Conor Dooley <conor.dooley@microchi=
p.com> wrote:
>
> Ah, thanks for the direct link :)

My pleasure!

> Actually, thinking about it for a moment - if only a single compiler
> version is supported (the minimum, right?) then you could just add the

Yeah, the minimum listed in `scripts/min-tool-version.sh` and in
`Documentation/process/changes.rst`. It also happens to be the maximum
too, until we can relax that.

> -Zsanitizer=3Dkcfi flag whenever CFI_CLANG and RUST are both set.

Since the flag goes to the Rust compiler, `RUST` would be always
enabled, so the flag would only need to be added when `CFI_CLANG=3Dy`,
no? Or what do you mean?

> I'm not sure if that is a better option though. It's a choice between
> CFI_CLANG being disabled if the check is not updated when the toolchain
> is bumped versus being enabled for C and not for RUST. I think I prefer
> the former though, tracking down the cause of the latter I would rather
> not wish on a user.
>
> I vote for having the check, even if it can only ever be true at the
> moment.

Since we only support a single version, we don't need `rc-option`
tests until we start supporting several versions (which is why other
tests like that do not exist so far).

In my previous message I thought you meant using the flag to test for
arch/target support or similar. That would be fine, but we can also do
the usual `ARCH_SUPPORTS_CFI_RUST` here, I would assume.

Now, during the version bump to a stable flag, if we happen to forget
to update the flag name, it would be a build error, so it should be
easily spotted and fixed. And if we did use an `rc-option` for the
arch/target support idea, it would be the first case you mention, so
it is all good.

What we may want to add, though, to avoid the confusion you mention
meanwhile, is just a `depends on !CFI_CLANG` for `RUST`, like for the
other requirements we have there (which are things that should
eventually go away). Then they can remove that when the `-Z` flag is
deemed ready to be used. But perhaps let's see what Ramon et al. say.

In other words, the flag was added back in 1.68.0 to `rustc`, but it
was not ready, so we need to store the "ready" bit in our side
meanwhile, i.e. we can't know that just by testing the flag itself.

By the way, concerning the tracking issue, since you mentioned it: it
has a list of PRs, but not fixes, there is a "known issues" link
there. On top of that, we are "shifted in time" w.r.t. the latest
status in the compiler, since we use stable versions of the compiler.

Cheers,
Miguel