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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANiq72k_dtr2=KX-WheUiM2v2370imAdWFawJR+8P41L7HjwpA@mail.gmail.com>
Date:   Fri, 15 Jul 2022 03:13:17 +0200
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Adam Bratschi-Kaye <ark.email@...il.com>,
        Alex Gaynor <alex.gaynor@...il.com>,
        Antonio Terceiro <antonio.terceiro@...aro.org>,
        Boqun Feng <boqun.feng@...il.com>,
        Boris-Chengbiao Zhou <bobo1239@....de>,
        Borislav Petkov <bp@...e.de>, Daniel Xu <dxu@...uu.xyz>,
        Dariusz Sosnowski <dsosnowski@...snowski.pl>,
        David Gow <davidgow@...gle.com>,
        Douglas Su <d0u9.su@...look.com>, Finn Behrens <me@...enk.de>,
        Gary Guo <gary@...yguo.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Miguel Cano <macanroj@...il.com>,
        Miguel Ojeda <ojeda@...nel.org>,
        Sven Van Asbroeck <thesven73@...il.com>,
        Wedson Almeida Filho <wedsonaf@...gle.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>
Subject: Re: linux-next: manual merge of the rust tree with Linus' tree

On Wed, Jul 13, 2022 at 1:40 PM Peter Zijlstra <peterz@...radead.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