From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C66581E9B0A; Tue, 7 Jan 2025 11:32:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736249530; cv=none; b=ReI72ERie1gwLFyowa0XfVVWLwGtmJv8BuNDdBmyaXrmcGK1ymbb/dCwSDWJ5o0E4Ft01xng8+9y0hVQ0gbYBsvIcTxgsqXq2Eu/sKQ7cTTzSNc/EGrXA68rZwdckDoY3mq7nMOAfswx6k00ReH5W6r8JTwbvYryKeIOmziMgtQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736249530; c=relaxed/simple; bh=phn3hwLXnNphs7vvlhjVmpFho6Dc/2pwkrPxE1EmRDQ=; h=From:To:Cc:Subject:In-Reply-To:Message-ID:References:Date: MIME-Version:Content-Type; b=SvGbozqq0Ly93+lTLYmoUHzydwpTf6g2G6oU6OizuIRE6kMwUN3F5A7gM6UaYQaC74EA2kxzx3KWkUnLt7czwLU1x2l1/aUIPV0NEQdEhIlvERKNjyf7p/EixzCwJKQSsfASp+fYOGFsyJWtkLioHbEPx/yLXwXi1bJlsllaTpE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=owHFS/n6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="owHFS/n6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2136AC4CED6; Tue, 7 Jan 2025 11:32:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736249529; bh=phn3hwLXnNphs7vvlhjVmpFho6Dc/2pwkrPxE1EmRDQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=owHFS/n6PeQp48GHDuuV3BdrmJnB1h9pACV5ka2DTlgaTWJs8lHDzmIfKi1EoCegp +owCgOp4ucRTyv5YOylTU3pLPHMVBniJj2YxdlUIlLD9t+9pG5c6GN3quyGpvrRGng YjfQilR51YZ1gs0UDephTo17w7HCw1mHdpK4fj8Nn20WH+1n6GDZSOfkbk02o9xz7I DGNUewwA143ZBFarKwXmepGK7SoeAWmsNybztCzp0YSMmCrfELaAUA7cbucpnbdGVq qZi0Sx1SmIuz5es2Rh+dbR0gk+otWSrAA4+7ZZa+D+2aFug7wcurVwDnJ15VUmOT/s Jx//h8pvNWOVg== From: Andreas Hindborg To: "Gary Guo" Cc: "Miguel Ojeda" , "Alex Gaynor" , "Boqun Feng" , =?us-ascii?Q?=3D=3Futf-8=3FQ=3FBj=3DC3=3DB6rn=3F=3D?= Roy Baron , "Benno Lossin" , "Alice Ryhl" , "Trevor Gross" , "Nathan Chancellor" , "Nick Desaulniers" , "Bill Wendling" , "Justin Stitt" , "Masahiro Yamada" , "Nicolas Schier" , "Andrew Morton" , "Dirk Behme" , "Tamir Duberstein" , "Christian Brauner" , "Martin Rodriguez Reboredo" , "Paul Moore" , "Wedson Almeida Filho" , "Steven Rostedt (Google)" , "Matt Gilbride" , "Danilo Krummrich" , "Eder Zulian" , "Filipe Xavier" , , , "Kees Cook" , "Daniel Xu" , , Subject: Re: [PATCH v2 2/3] kbuild: rust: provide an option to inline C helpers into Rust In-Reply-To: <20250105194054.545201-3-gary@garyguo.net> (Gary Guo's message of "Sun, 05 Jan 2025 19:40:05 +0000") Message-ID: <87msg26fxt.fsf@kernel.org> References: <20250105194054.545201-1-gary@garyguo.net> <20250105194054.545201-3-gary@garyguo.net> User-Agent: mu4e 1.12.7; emacs 29.4 Date: Tue, 07 Jan 2025 12:31:32 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain "Gary Guo" writes: > A new Kconfig option, `RUST_INLINE_HELPERS` is added to allow C helpers > (which was created to allow Rust to call into inline/macro C functions > without having to re-implement the logic in Rust) to be inlined into > Rust crates without performing a global LTO. > > If the option is enabled, the following is performed: > * For helpers, instead of compiling them to object file to be linked > into vmlinux, we compile them to LLVM IR. > * The LLVM IR is patched to add `linkonce_odr` linkage. This linkage > means that the function is inlineable (effect of `_odr`), and the > symbols generated will have weak linkage if emitted into object file > (important since as later described, we might have multiple copies of > the same symbol) and it will may be discarded if it is not invoked or > all invocations are inlined. > * The LLVM IR is compiled to bitcode (This is step is not necessary, but > is a performance optimisation to prevent LLVM from always have to > reparse the same IR). > * When a Rust crate is compiled, instead of generating object file, we > ask LLVM bitcode to be generated. > * llvm-link is invoked to combine the helper bitcode with the crate > bitcode. This step is similar to LTO, but this is much faster since it > only needs to inline the helpers. > * clang is invoked to turn the combined bitcode into object file. > > Some caveats with the option: > * clang and Rust doesn't have the exact target string. Manual inspection > shows that they should be compatible, but since they are not exactly > the same LLVM seems to prefer not inlining them. This is bypassed with > `--ignore-tti-inline-compatible`. > * LLVM doesn't want to inline functions combined with > `-fno-delete-null-pointer-checks` with code compiled without. So we > remove this command when compiling helpers. I think this should be > okay since this is one of the hardening features and we shouldn't have > null pointer dereferences in these helpers. > > The checks can also be bypassed with force inlining (`__always_inline`) > but the behaviour is the same with extra options. > > Co-developed-by: Boqun Feng > Signed-off-by: Boqun Feng > Signed-off-by: Gary Guo Reviewed-by: Andreas Hindborg Tested-by: Andreas Hindborg Tested with downstream rnull tree, works as expected. Best regards, Andreas Hindborg