Re: [PATCH] rust: enable fentry support

On Wed, Jul 29, 2026 at 12:57:48AM +0200, Vasily Gorbik wrote:

On Mon, Jul 27, 2026 at 08:33:35PM +0200, Miguel Ojeda wrote:

quoted

On Mon, Jul 27, 2026 at 7:18 PM Paul Murphy [off-list ref] wrote:

quoted

Hrm, s390x has more nuanced usage. It still uses -mrecord-mcount and
-mnop-mcount. The x86 configurations I've looked at use the kernel's
tooling to nop and record as needed. Is there any reason s390x cannot
use those, or should rustc support those (for s390x only)?

So I do not think -mrecord-mcount Rust support is only needed for
s390. The Rust build path needs an equivalent of -mrecord-mcount when
FTRACE_MCOUNT_USE_CC is selected. And additionally an equivalent of
-mnop-mcount for s390 (this is debatable, we could check if this brings
us much or we could drop it).

Ok, I refreshed my memory on why exactly we stick to using -mnop-mcount:
it is not just an optimization that saves us a few milliseconds on the
initial NOP conversion.

s390 deliberately uses the same six-byte disabled function prologue for
both supported compiler paths:

  older compilers using -mhotpatch=0,3:
    brcl 0,0

  newer compilers using -mfentry -mnop-mcount:
    brcl 0,0

Without -mnop-mcount, the newer path would instead emit:

    brasl %r0,__fentry__

s390 would then need to support multiple initial prologue formats,
provide and export a no-op __fentry__ implementation, handle its module
relocations and PLTs, and distinguish fentry calls from hotpatch-generated
NOPs during initialization. -mnop-mcount avoids this and keeps the old
hotpatch path and the newer fentry path binary-compatible.

Since LLVM's SystemZ backend already implements the "mrecord-mcount" and
"mnop-mcount", teaching rustc to request those existing backend operations
appears considerably cleaner than reintroducing multiple s390 prologue
formats and startup conversion.