Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220713203409.559c5464@canb.auug.org.au> <Ys6u88DqQdgmkWWf@hirez.programming.kicks-ass.net>
In-Reply-To: <Ys6u88DqQdgmkWWf@hirez.programming.kicks-ass.net>
From:   Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date:   Fri, 15 Jul 2022 03:13:17 +0200
Message-ID: <CANiq72k_dtr2=KX-WheUiM2v2370imAdWFawJR+8P41L7HjwpA@mail.gmail.com>
Subject: Re: linux-next: manual merge of the rust tree with Linus' tree
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Stephen Rothwell <sfr@canb.auug.org.au>,
        Adam Bratschi-Kaye <ark.email@gmail.com>,
        Alex Gaynor <alex.gaynor@gmail.com>,
        Antonio Terceiro <antonio.terceiro@linaro.org>,
        Boqun Feng <boqun.feng@gmail.com>,
        Boris-Chengbiao Zhou <bobo1239@web.de>,
        Borislav Petkov <bp@suse.de>, Daniel Xu <dxu@dxuuu.xyz>,
        Dariusz Sosnowski <dsosnowski@dsosnowski.pl>,
        David Gow <davidgow@google.com>,
        Douglas Su <d0u9.su@outlook.com>, Finn Behrens <me@kloenk.de>,
        Gary Guo <gary@garyguo.net>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux Next Mailing List <linux-next@vger.kernel.org>,
        Michael Ellerman <mpe@ellerman.id.au>,
        Miguel Cano <macanroj@gmail.com>,
        Miguel Ojeda <ojeda@kernel.org>,
        Sven Van Asbroeck <thesven73@gmail.com>,
        Wedson Almeida Filho <wedsonaf@google.com>,
        Nick Desaulniers <ndesaulniers@google.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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