Re: [PATCH] rust: enable fentry support

Re: [PATCH] rust: enable fentry support

[Vasily Gorbik]

On Mon, Jul 27, 2026 at 08:33:35PM +0200, Miguel Ojeda wrote:
> On Mon, Jul 27, 2026 at 7:18 PM Paul Murphy <paumurph@redhat.com> 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)?
> 
> Cc'ing the s390x maintainers -- they probably know why they use them.

Cc'ing the ftrace maintainers.

I do not think this is true for x86 in general. Generating the
__fentry__ call and recording its location are two separate operations.
-Zinstrument-mcount=fentry only generates the call. Dynamic ftrace also
needs the call site recorded in __mcount_loc section.

The recording mechanism is selected in kernel/trace/Kconfig:

config FTRACE_MCOUNT_USE_CC
   def_bool y
   depends on $(cc-option,-mrecord-mcount)
   depends on !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY
   depends on DYNAMIC_FTRACE

config FTRACE_MCOUNT_USE_OBJTOOL
   def_bool y
   depends on HAVE_OBJTOOL_MCOUNT
   depends on !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY
   depends on !FTRACE_MCOUNT_USE_CC                <--- NOTICE THAT --
   depends on DYNAMIC_FTRACE
   select OBJTOOL

config FTRACE_MCOUNT_USE_RECORDMCOUNT
   def_bool y
   depends on !FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY
   depends on !FTRACE_MCOUNT_USE_CC
   depends on !FTRACE_MCOUNT_USE_OBJTOOL
   depends on DYNAMIC_FTRACE

There are currently three ways to generate __mcount_loc section:

1. The compiler does it with -mrecord-mcount.
2. Objtool does it with --mcount.
3. scripts/recordmcount does it as a post-processing step.

These are selected in that order.

Looking on my system:

For x86 GCC builds - current GCC supports -mrecord-mcount,
so FTRACE_MCOUNT_USE_CC is selected and the compiler gets

  -pg -mfentry -mrecord-mcount

For x86 Clang builds - current x86 Clang does not support -mrecord-mcount,
so FTRACE_MCOUNT_USE_OBJTOOL is selected. Clang gets

  -pg -mfentry

and objtool gets

  --mcount --mnop

s390 uses the compiler path with both current GCC and Clang:

  -pg -mfentry -mrecord-mcount -mnop-mcount

Here -mrecord-mcount creates __mcount_loc and -mnop-mcount emits the
six-byte nop expected by the s390 ftrace code.

So -Zinstrument-mcount=fentry alone is sufficient only when some
later build step records the generated call, as objtool does for
x86 Clang FTRACE_MCOUNT_USE_OBJTOOL builds. It is not sufficient for
FTRACE_MCOUNT_USE_CC. For FTRACE_MCOUNT_USE_RECORDMCOUNT - the
scripts/recordmcount post-processing step is also currently wired to
the C build rule rather than the Rust build rule.

Objtool mcount recording is currently supported only by x86 and powerpc.
Those are the only architectures which select HAVE_OBJTOOL_MCOUNT. And
s390 currently has no objtool support.

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).

Re: [PATCH] rust: enable fentry support

[Paul Murphy]

On Tue, Jul 28, 2026 at 5:58 PM Vasily Gorbik <gor@linux.ibm.com> wrote:

> 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).

Right, as background, the llvm x86 maintainer were uninterested in
supporting these options [1] when I created the PR. I think the
argument is roughly that these options are bespoke features for
building this project. mrecordmcount already does that, independent of
the compiler. I think some llvm maintainers hold the opinion that
patchable-function-entries is already a sufficient replacement for
fentry.

Digging through commit history, the answer is unsurprisingly that
using recordmcount is slower. It's certainly more convenient to have
the compiler record them.

[1] https://github.com/llvm/llvm-project/pull/184641

Re: [PATCH] rust: enable fentry support

[Vasily Gorbik]

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 <paumurph@redhat.com> 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.