Received-SPF: pass (google.com: domain of linux-kernel+bounces-38580-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Thu, 25 Jan 2024 12:30:34 +0000
From: Conor Dooley <conor.dooley@microchip.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.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>, =?iso-8859-1?Q?Bj=F6rn?= 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: Re: [PATCH v1 0/2] RISC-V: enable rust
Message-ID: <20240125-bucked-payroll-47f82077b262@wendy>
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>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="mujnSF4ge/jontNh"
Content-Disposition: inline
In-Reply-To: <CANiq72nx1s_nyvPW86jL7eiOxROr18LfOJqNtw8L42CP+gkhRg@mail.gmail.com>

--mujnSF4ge/jontNh
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 18, 2024 at 05:09:40PM +0100, Miguel Ojeda wrote:
> On Thu, Jan 18, 2024 at 4:49=E2=80=AFPM Conor Dooley <conor@kernel.org> w=
rote:
> >
> > The bit that worries me most is bindgen, and in particular detecting the
> > version of libclang used. I mentioned to Nathan or Nick about needing a
> > buildtime test for the version of LIBCLANG being used.
> > I'm less worried about this for LLVM=3D1 builds, since while I think it=
 is
> > possible to provide a LIBCLANG path to the build system, I suspect that
> > for LLVM=3D1 builds it's almost always going to match the LLVM toolchain
> > in use.

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.

> `scripts/rust_is_available.sh` tests whether `libclang` is at least
> the minimum LLVM supported version; and under `LLVM=3D1` builds, it also
> tests whether the `bindgen` found one matches the C compiler. Do you
> mean something like that?

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.

> 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/288089=
-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.

> > I'll do another rebase and resend after the merge window closes I
> > suppose :)


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?

The tracking issue seems to be complete:
https://github.com/rust-lang/rust/issues/89653
but the tracking issue for sanitisiers themselves is only 3/5:
https://github.com/rust-lang/rust/issues/39699

The simple thing would be to make them mutually exclusive options in
Kconfig.

What do you think?

Cheers,
Conor.

--mujnSF4ge/jontNh
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZbJUXAAKCRB4tDGHoIJi
0uVHAQDIljZB931BuYsvFh8CDiXkeXE86yDu7dnEqYO2MErRBwEArNXVKUHQ6zGx
JQPxBR+Fd23f1rnzfJFcWNiA7BscMA8=
=IPeL
-----END PGP SIGNATURE-----

--mujnSF4ge/jontNh--