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:
> > On Mon, Jul 27, 2026 at 7:18 PM Paul Murphy <[email protected]> wrote:
> > >
> > > 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.
