Re: [PATCH 2/4] rust: helpers: #define __rust_helper

[Andreas Hindborg]

Alice Ryhl <aliceryhl@xxxxxxxxxx> writes:

> From: Gary Guo <gary@xxxxxxxxxxx>
>
> 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.
>
> The actual additions of __rust_helper can happen in separate patches. A
> "flag day" change is not required since missing annotations do not lead
> to anything worse than missing inlining.
>
> Signed-off-by: Gary Guo <gary@xxxxxxxxxxx>
> Signed-off-by: Alice Ryhl <aliceryhl@xxxxxxxxxx>

Reviewed-by: Andreas Hindborg <a.hindborg@xxxxxxxxxx>


Best regards,
Andreas Hindborg