[PATCH] rust: enable fentry support

[PATCH] rust: enable fentry support

[Paul Murphy]

Turn it on when available if CONFIG_HAVE_FENTRY=y.

Rust support was added in 1.98.0 with support for x86 and s390x targets.

Signed-off-by: Paul Murphy <murp@redhat.com>
---
 Makefile                        | 2 ++
 scripts/generate_rust_target.rs | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/Makefile b/Makefile
index bfb47ad8cb9a..bdfe93702a33 100644
--- a/Makefile
+++ b/Makefile
@@ -1053,10 +1053,12 @@ ifdef CONFIG_HAVE_FENTRY
     CC_FLAGS_FTRACE	+= -mfentry
     CC_FLAGS_USING	+= -DCC_USING_FENTRY
   endif
+  RUSTFLAGS_FTRACE := $(if $(call rustc-min-version,109800),-Zinstrument-mcount=fentry,)
 endif
 export CC_FLAGS_FTRACE
 KBUILD_CFLAGS	+= $(CC_FLAGS_FTRACE) $(CC_FLAGS_USING)
 KBUILD_AFLAGS	+= $(CC_FLAGS_USING)
+KBUILD_RUSTFLAGS += $(RUSTFLAGS_FTRACE)
 endif
 
 # We trigger additional mismatches with less inlining
diff --git a/scripts/generate_rust_target.rs b/scripts/generate_rust_target.rs
index 3bf296581a88..eb80a06d50d3 100644
--- a/scripts/generate_rust_target.rs
+++ b/scripts/generate_rust_target.rs
@@ -198,6 +198,7 @@ fn main() {
         ts.push("arch", "x86_64");
         if cfg.rustc_version_atleast(1, 98, 0) {
             ts.push("rustc-abi", "softfloat");
+            ts.push("supports-fentry", true);
         } else if cfg.rustc_version_atleast(1, 86, 0) {
             ts.push("rustc-abi", "x86-softfloat");
         }
@@ -240,6 +241,7 @@ fn main() {
         ts.push("arch", "x86");
         if cfg.rustc_version_atleast(1, 98, 0) {
             ts.push("rustc-abi", "softfloat");
+            ts.push("supports-fentry", true);
         } else if cfg.rustc_version_atleast(1, 86, 0) {
             ts.push("rustc-abi", "x86-softfloat");
         }

base-commit: 7059bdf4f04a3e14f4fafb3ac35fdca913e3e21a
-- 
2.55.0

Re: [PATCH] rust: enable fentry support

[Miguel Ojeda]

On Fri, Jul 24, 2026 at 7:01 PM Paul Murphy <murp@redhat.com> wrote:
>
> Rust support was added in 1.98.0 with support for x86 and s390x targets.

"will be added"? i.e. it is not released, but I guess you mean it is
unusual to drop from beta.

Link: https://github.com/rust-lang/rust/pull/152122
Link: https://github.com/rust-lang/rust/pull/158036

Cheers,
Miguel

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.