Message ID | 20211206140313.5653-6-ojeda@kernel.org (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | Rust support | expand |
On Mon, Dec 6, 2021 at 6:05 AM Miguel Ojeda <ojeda@kernel.org> wrote: > > Rust provides `compiler_builtins` as a port of LLVM's `compiler-rt`. > Since we do not need the vast majority of them, we avoid the > dependency by providing our own crate. > > Co-developed-by: Alex Gaynor <alex.gaynor@gmail.com> > Signed-off-by: Alex Gaynor <alex.gaynor@gmail.com> > Co-developed-by: Wedson Almeida Filho <wedsonaf@google.com> > Signed-off-by: Wedson Almeida Filho <wedsonaf@google.com> > Co-developed-by: Sven Van Asbroeck <thesven73@gmail.com> > Signed-off-by: Sven Van Asbroeck <thesven73@gmail.com> > Co-developed-by: Gary Guo <gary@garyguo.net> > Signed-off-by: Gary Guo <gary@garyguo.net> > Signed-off-by: Miguel Ojeda <ojeda@kernel.org> > --- > rust/compiler_builtins.rs | 57 +++++++++++++++++++++++++++++++++++++++ > 1 file changed, 57 insertions(+) > create mode 100644 rust/compiler_builtins.rs > > diff --git a/rust/compiler_builtins.rs b/rust/compiler_builtins.rs > new file mode 100644 > index 000000000000..a5a0be72591b > --- /dev/null > +++ b/rust/compiler_builtins.rs > @@ -0,0 +1,57 @@ > +// SPDX-License-Identifier: GPL-2.0 > + > +//! Our own `compiler_builtins`. > +//! > +//! Rust provides [`compiler_builtins`] as a port of LLVM's [`compiler-rt`]. > +//! Since we do not need the vast majority of them, we avoid the dependency > +//! by providing this file. > +//! > +//! At the moment, some builtins are required that should not be. For instance, > +//! [`core`] has floating-point functionality which we should not be compiling > +//! in. We will work with upstream [`core`] to provide feature flags to disable > +//! the parts we do not need. For the moment, we define them to [`panic!`] at > +//! runtime for simplicity to catch mistakes, instead of performing surgery Rather than panic at runtime, could we do some binary post processing in Kbuild with $(NM) to error the build if any of the below symbols are referenced from .o files produced by .rs sources? If we provide definitions of these symbols, then I worry about C code that previously would have failed to link at build time when referencing these will now succeed at linking when CONFIG_RUST=y is enabled, but may panic at runtime IF we happen to hit those code paths. > +//! on `core.o`. > +//! > +//! In any case, all these symbols are weakened to ensure we do not override > +//! those that may be provided by the rest of the kernel. > +//! > +//! [`compiler_builtins`]: https://github.com/rust-lang/compiler-builtins > +//! [`compiler-rt`]: https://compiler-rt.llvm.org/ > + > +#![feature(compiler_builtins)] > +#![compiler_builtins] > +#![no_builtins] > +#![no_std] > + > +macro_rules! define_panicking_intrinsics( > + ($reason: tt, { $($ident: ident, )* }) => { > + $( > + #[doc(hidden)] > + #[no_mangle] > + pub extern "C" fn $ident() { > + panic!($reason); > + } > + )* > + } > +); > + > +define_panicking_intrinsics!("`i128` should not be used", { > + __ashrti3, > + __muloti4, > + __multi3, > +}); > + > +define_panicking_intrinsics!("`u128` should not be used", { > + __ashlti3, > + __lshrti3, > + __udivmodti4, > + __udivti3, > + __umodti3, > +}); > + > +#[cfg(target_arch = "arm")] > +define_panicking_intrinsics!("`u64` division/modulo should not be used", { > + __aeabi_uldivmod, > + __mulodi4, > +}); > -- > 2.34.0 >
On Wed, Dec 8, 2021 at 12:02 AM Nick Desaulniers <ndesaulniers@google.com> wrote: > > Rather than panic at runtime, could we do some binary post processing > in Kbuild with $(NM) to error the build if any of the below symbols > are referenced from .o files produced by .rs sources? To error the build, we only need to not define them; i.e. the issue is passing the build. Eventually, we should be able to avoid defining them (this is what the comment is referring to). There are other ways around, like providing an in-tree `core`, but it is best to see if upstream Rust can do it. > If we provide definitions of these symbols, then I worry about C code > that previously would have failed to link at build time when > referencing these will now succeed at linking when CONFIG_RUST=y is > enabled, but may panic at runtime IF we happen to hit those code > paths. It should be fine -- by the time we consider the Rust support non-experimental, we should not be defining them. Cheers, Miguel
diff --git a/rust/compiler_builtins.rs b/rust/compiler_builtins.rs new file mode 100644 index 000000000000..a5a0be72591b --- /dev/null +++ b/rust/compiler_builtins.rs @@ -0,0 +1,57 @@ +// SPDX-License-Identifier: GPL-2.0 + +//! Our own `compiler_builtins`. +//! +//! Rust provides [`compiler_builtins`] as a port of LLVM's [`compiler-rt`]. +//! Since we do not need the vast majority of them, we avoid the dependency +//! by providing this file. +//! +//! At the moment, some builtins are required that should not be. For instance, +//! [`core`] has floating-point functionality which we should not be compiling +//! in. We will work with upstream [`core`] to provide feature flags to disable +//! the parts we do not need. For the moment, we define them to [`panic!`] at +//! runtime for simplicity to catch mistakes, instead of performing surgery +//! on `core.o`. +//! +//! In any case, all these symbols are weakened to ensure we do not override +//! those that may be provided by the rest of the kernel. +//! +//! [`compiler_builtins`]: https://github.com/rust-lang/compiler-builtins +//! [`compiler-rt`]: https://compiler-rt.llvm.org/ + +#![feature(compiler_builtins)] +#![compiler_builtins] +#![no_builtins] +#![no_std] + +macro_rules! define_panicking_intrinsics( + ($reason: tt, { $($ident: ident, )* }) => { + $( + #[doc(hidden)] + #[no_mangle] + pub extern "C" fn $ident() { + panic!($reason); + } + )* + } +); + +define_panicking_intrinsics!("`i128` should not be used", { + __ashrti3, + __muloti4, + __multi3, +}); + +define_panicking_intrinsics!("`u128` should not be used", { + __ashlti3, + __lshrti3, + __udivmodti4, + __udivti3, + __umodti3, +}); + +#[cfg(target_arch = "arm")] +define_panicking_intrinsics!("`u64` division/modulo should not be used", { + __aeabi_uldivmod, + __mulodi4, +});