From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 269E0C433FE for ; Tue, 7 Dec 2021 23:02:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242271AbhLGXFl (ORCPT ); Tue, 7 Dec 2021 18:05:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55368 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238183AbhLGXFl (ORCPT ); Tue, 7 Dec 2021 18:05:41 -0500 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 12D4DC061746 for ; Tue, 7 Dec 2021 15:02:10 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id d10so1785698lfg.6 for ; Tue, 07 Dec 2021 15:02:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XeysCYKuIXT30NpKmxVW0LuuA+5Y9jF9W/gtwz7ItQs=; b=FjWKHHI5PiBkeM53HJ0SJ8QW3pwZzOqQOjK+ZF5sx7OT+T49loOhaddpCBDI3KVtK9 G3W8JoJaT2gLeh23K56rW0XqsGUDfQBWPSlRUpiyMBWrwRESbpCREPfznGpocHMz9Jf5 KTn8soeKulfYk3hqMUD/z7Zx8owzOzX8VkcMydwtoEQ4GmTJslVi0R5449kC+szdM4Dx m241C13+coQvCrtRQ7yj49/uRQCajqIkjkKLC/NBjympTCs3D4ZvTaSfN02gjAqsMnGN Ur9lQfMbX0byWz8vRjiI6d+I1nRqKhZIfuxK7hwvnuoLl+PiVBQLZEASabzSEx7CyYaG Is1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XeysCYKuIXT30NpKmxVW0LuuA+5Y9jF9W/gtwz7ItQs=; b=LdO4UIZJhfgeTitayKq6bGsP5bVDJtJchKHsQxZWZMDyVdnZejdwWvjOgHAX1Kycau eZKGYUl7or0kakoLr8tiq0Be2klSAzNd2lzuSMuRhbTONghjrTc6q/U1Ts1LebX5yE0O aynJHFRnmMYr2TjS/CY0A/xuRMLmm7hBswC5cGHHH8az5Creaoa/vZXctsUTiLrIqvbv Y+FVPoM4drKlE01JvHxRuqkAWQ1NKYujXnLUzm7l9DyCCUzr6oC6gGkCH4+lhli1/AFA xb3JbJn5XAMiwBTq3jG2JBoPHktc124PoweDD1Oe9jwMfSqyh6hGqHHf7Xytr/XPObZp GpuQ== X-Gm-Message-State: AOAM531uIVZppUguz9jRzJ9wU+JVzyBlTdIra7N6vHq9DYGC4/LfNaYv gsl2RCgqmINI3PkqLToZLbqUweU0p21oqtDHvGIBiA== X-Google-Smtp-Source: ABdhPJycRpNrtmgPnLthJBwXFriPhrz3LH63dzqAVAo1jcSHKR5llRWJKZLjakqcbvDHbnK3EfH8MLGqnfo8YgsG0oo= X-Received: by 2002:a05:6512:228c:: with SMTP id f12mr14294851lfu.550.1638918128028; Tue, 07 Dec 2021 15:02:08 -0800 (PST) MIME-Version: 1.0 References: <20211206140313.5653-1-ojeda@kernel.org> <20211206140313.5653-6-ojeda@kernel.org> In-Reply-To: <20211206140313.5653-6-ojeda@kernel.org> From: Nick Desaulniers Date: Tue, 7 Dec 2021 15:01:56 -0800 Message-ID: Subject: Re: [PATCH 05/19] rust: add `compiler_builtins` crate To: Miguel Ojeda , Linux Kbuild mailing list , Masahiro Yamada Cc: Linus Torvalds , Greg Kroah-Hartman , rust-for-linux@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Alex Gaynor , Wedson Almeida Filho , Sven Van Asbroeck , Gary Guo Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: rust-for-linux@vger.kernel.org On Mon, Dec 6, 2021 at 6:05 AM Miguel Ojeda 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 > Signed-off-by: Alex Gaynor > Co-developed-by: Wedson Almeida Filho > Signed-off-by: Wedson Almeida Filho > Co-developed-by: Sven Van Asbroeck > Signed-off-by: Sven Van Asbroeck > Co-developed-by: Gary Guo > Signed-off-by: Gary Guo > Signed-off-by: Miguel Ojeda > --- > 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 > -- Thanks, ~Nick Desaulniers