Skip to content

Commit db70281

Browse files
nbdd0121ojeda
authored andcommitted
rust: helpers: #define __rust_helper
Because of LLVM inling checks, it's generally not possible to inline a C helper into Rust code, even with LTO: * LLVM doesn't want to inline functions compiled with `-fno-delete-null-pointer-checks` with code compiled without. The C CGUs all have this enabled and Rust CGUs don't. Inlining is okay since this is one of the hardening features that does not change the ABI, and we shouldn't have null pointer dereferences in these helpers. * LLVM doesn't want to inline functions with different list of builtins. C side has `-fno-builtin-wcslen`; `wcslen` is not a Rust builtin, so they should be compatible, but LLVM does not perform inlining due to attributes mismatch. * clang and Rust doesn't have the exact target string. Clang generates `+cmov,+cx8,+fxsr` but Rust doesn't enable them (in fact, Rust will complain if `-Ctarget-feature=+cmov,+cx8,+fxsr` is used). x86-64 always enable these features, so they are in fact the same target string, but LLVM doesn't understand this and so inlining is inhibited. This can be bypassed with `--ignore-tti-inline-compatible`, but this is a hidden option. To fix this, we can add __always_inline on every helper, which skips these LLVM inlining checks. For this purpose, introduce a new __rust_helper macro that needs to be added to every helper. Most helpers already have __rust_helper specified, but there are a few missing. The only consequence of this is that those specific helpers do not get inlined. Signed-off-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://patch.msgid.link/20260203-inline-helpers-v2-2-beb8547a03c9@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
1 parent e90f97c commit db70281

File tree

1 file changed

+29
-0
lines changed

1 file changed

+29
-0
lines changed

rust/helpers/helpers.c

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,36 @@
77
* Sorted alphabetically.
88
*/
99

10+
#include <linux/compiler_types.h>
11+
12+
#ifdef __BINDGEN__
13+
// Omit `inline` for bindgen as it ignores inline functions.
1014
#define __rust_helper
15+
#else
16+
// The helper functions are all inline functions.
17+
//
18+
// We use `__always_inline` here to bypass LLVM inlining checks, in case the
19+
// helpers are inlined directly into Rust CGUs.
20+
//
21+
// The LLVM inlining checks are false positives:
22+
// * LLVM doesn't want to inline functions compiled with
23+
// `-fno-delete-null-pointer-checks` with code compiled without.
24+
// The C CGUs all have this enabled and Rust CGUs don't. Inlining is okay
25+
// since this is one of the hardening features that does not change the ABI,
26+
// and we shouldn't have null pointer dereferences in these helpers.
27+
// * LLVM doesn't want to inline functions with different list of builtins. C
28+
// side has `-fno-builtin-wcslen`; `wcslen` is not a Rust builtin, so they
29+
// should be compatible, but LLVM does not perform inlining due to attributes
30+
// mismatch.
31+
// * clang and Rust doesn't have the exact target string. Clang generates
32+
// `+cmov,+cx8,+fxsr` but Rust doesn't enable them (in fact, Rust will
33+
// complain if `-Ctarget-feature=+cmov,+cx8,+fxsr` is used). x86-64 always
34+
// enable these features, so they are in fact the same target string, but
35+
// LLVM doesn't understand this and so inlining is inhibited. This can be
36+
// bypassed with `--ignore-tti-inline-compatible`, but this is a hidden
37+
// option.
38+
#define __rust_helper __always_inline
39+
#endif
1140

1241
#include "atomic.c"
1342
#include "atomic_ext.c"

0 commit comments

Comments
 (0)