Received-SPF: pass (google.com: domain of linux-kernel+bounces-38595-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
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>
In-Reply-To: <20240125-bucked-payroll-47f82077b262@wendy>
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date: Thu, 25 Jan 2024 13:50:05 +0100
Message-ID: <CANiq72k7n0aZrifRRU08N8qLkNe+2EZwijZy5sM7M56n2xYHgQ@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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 25, 2024 at 1:31=E2=80=AFPM Conor Dooley <conor.dooley@microchi=
p.com> wrote:
>
> I chatted with the clang built linux folks about this yesterday, Nathan
> agreed that dealing with incompatibility issues iff they crop up is a
> reasonable way to go.
>
> If by "the bindgen found one matches the C compiler" you mean that the
> version of libclang used by bindgen matches the C compiler, then that
> sounds great.

Yeah, exactly. So, unless I am misunderstanding, the incompatibilities
could only happen if someone ignores the warning. We could make it an
error too.

> > For `bindgen` under GCC builds, we will eventually want a "proper" way
> > to use GCC instead (or possibly other approaches like querying the
> > information): https://github.com/rust-lang/rust-bindgen/issues/1949.
>
> > Recently, there has been a thread in our Zulip and a couple people are
> > experimenting: https://rust-for-linux.zulipchat.com/#narrow/stream/2880=
89-General/topic/Bindgen.20--.20GCC.20backend.20port
>
> That link for me goes to a message on 22/01, so later than the email you
> sent.

Zulip seems to scroll to the latest message in the topic -- you should
be able to scroll a bit up, but if that doesn't work, this link should
go to the first message:
https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/Bi=
ndgen.20--.20GCC.20backend.20port/near/412609074

> That said, I gave things another spin today, in a different environment,
> as a final check before sending and found an issue causing kernel
> panics. RISC-V (and x86/arm64) supports kcfi (CFI_CLANG) but enabling
> sanitisers seems to be a nightly only option for rustc. The kernel I
> built today had CFI_CLANG enabled and that caused panics when the rust
> samples were loaded.
>
> The CFI_CLANG Kconfig entry has a cc-option test for whether the option
> is supported, but from a quick check I don't see a comparable test to
> use for rust. Even if a test was added, the current flag is an unstable
> one, so I am not sure if testing for it is the right call in the first
> place, given the stabilised flag would be entirely different?

Yeah, KCFI and other mitigations is WIP -- Cc'ing Ramon and Matthew
who may be able to tell us the latest status.

Testing for unstable flags is fine, i.e. we only support a single
compiler, so we can change the name when we do the upgrade.

Cheers,
Miguel