Re: linux-next: manual merge of the rust tree with Linus' tree

[Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>]

On Wed, Jul 13, 2022 at 1:40 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> Does Rust have the equivalent of -mfunction-return=thunk-extern ?

While GCC has had it for a while, Nick just landed 2 days ago the
X86ReturnThunks pass in LLVM, so it will take some time to arrive in
rustc.

I have naively backported it to rustc and hacked it so that I set the
LLVM attribute for all functions, and I am getting the rets replaced
in Rust functions, e.g.

(gdb) disassemble a::f
Dump of assembler code for function _ZN1a1f17hdc6112b1b4a4fe99E:
   ...
   0x0000000000008a1f <+31>: pop    %rbp
   0x0000000000008a20 <+32>: jmp    0x8ce0 <__x86_return_thunk>

A trivial userspace program that counts the times that it goes through
the return thunk also appears to work.

> Related, how does Rust deal with all the various CC_HAS_ Kconfig stuff?
> What if C has the relevant option but Rust does not; then we must not
> have the feature enabled or there will be a mis-match.

I guess that would depend on the particular option: whether it applies
to Rust at all, whether it creates an incompatibility or not, etc.

> Do we now have to litter everythign with RUSTC_HAS_ ?

Why? Only a single `rustc` version is targeted at the moment, so it is
possible to statically know what it supports.

And later on, when we can declare a minimum version or when a second
compiler is ready, sure, we may need to have options depending on what
we want to do. Why would that be a problem?

Cheers,
Miguel