[PATCH 1/1] perf build: Fix Python extension build with GCC 16 hardening

[PATCH 1/1] perf build: Fix Python extension build with GCC 16 hardening

[Jan Polensky]

The Python extension build fails with modern GCC versions (16+) due to
the new hardening feature that prevents dynamic relocations in read-only
segments:

  /usr/bin/ld.bfd: error: read-only segment has dynamic relocations
  collect2: error: ld returned 1 exit status

This occurs when building the perf Python bindings because the linker
enforces stricter security policies by default.

Add -Wl,-z,notext to LDSHARED to explicitly allow text relocations in
the Python extension shared object. This is necessary for the Python
C extension to link successfully while maintaining compatibility with
the Python build system.

The flag only affects the Python extension build and does not impact
the security of the main perf binary or other components.

Tested on Fedora 44 with GCC 16.1.1 20260501 (Red Hat 16.1.1-1) and
Python 3.14.4 on s390x architecture.

Reported-by: Thomas Richter <tmricht@linux.ibm.com>
Signed-off-by: Jan Polensky <japo@linux.ibm.com>
---
 tools/perf/Makefile.perf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index bfb37f527241..12af424dd5c1 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -749,7 +749,7 @@ all: shell_compatibility_test $(ALL_PROGRAMS) $(LANG_BINDINGS) $(OTHER_PROGRAMS)
 $(shell [ -d '$(OUTPUT)python' ] || mkdir -p '$(OUTPUT)python')
 
 $(OUTPUT)python/perf$(PYTHON_EXTENSION_SUFFIX): util/python.c util/setup.py $(PERFLIBS_PY)
-	$(QUIET_GEN)LDSHARED="$(CC) -pthread -shared" \
+	$(QUIET_GEN)LDSHARED="$(CC) -pthread -shared -Wl,-z,notext" \
         CFLAGS='$(CFLAGS)' LDFLAGS='$(LDFLAGS) $(LIBS_PY)' \
 	  $(PYTHON_WORD) util/setup.py \
 	  --quiet build_ext; \
-- 
2.51.0

Re: [PATCH 1/1] perf build: Fix Python extension build with GCC 16 hardening

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch explicitly allows text relocations in the Python extension shared object (`perf.so`) by adding `-Wl,-z,notext`, masking the root cause of missing `-fPIC` flags and breaking W^X (Write XOR Execute) security protections.
--

commit f3832fb0ad0d1f9c2e69039b2a5110f77d220d5e
Author: Jan Polensky <japo@linux.ibm.com>

perf build: Fix Python extension build with GCC 16 hardening

This commit addresses a build failure in the Python extension caused by GCC 16
stricter security policies regarding dynamic relocations in read-only segments.
It adds the -Wl,-z,notext flag to the linker to explicitly allow text
relocations in the Python extension shared object.

> diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> index 76b35ac19acbf..eea170d6576db 100644
> --- a/tools/perf/Makefile.perf
> +++ b/tools/perf/Makefile.perf
> @@ -749,7 +749,7 @@ all: shell_compatibility_test $(ALL_PROGRAMS) $(LANG_BINDINGS) $(OTHER_PROGRAMS)
>  $(shell [ -d '$(OUTPUT)python' ] || mkdir -p '$(OUTPUT)python')
>  
>  $(OUTPUT)python/perf$(PYTHON_EXTENSION_SUFFIX): util/python.c util/setup.py $(PERFLIBS_PY)
> -	$(QUIET_GEN)LDSHARED="$(CC) -pthread -shared" \
> +	$(QUIET_GEN)LDSHARED="$(CC) -pthread -shared -Wl,-z,notext" \

[Severity: Medium]
Does adding -Wl,-z,notext mask the root cause of the GCC 16 linker error?

The error regarding dynamic relocations in a read-only segment usually
indicates that non-position-independent code from the static libraries
is being linked into the shared library.

Using -Wl,-z,notext suppresses this error by allowing text relocations, which
forces the dynamic linker to map the executable text segment as writable at
load time. This breaks W^X security protections and weakens the security of
any Python process loading the extension.

Should the required object files be compiled with -fPIC instead to properly
resolve the linker error without compromising security?

>          CFLAGS='$(CFLAGS)' LDFLAGS='$(LDFLAGS) $(LIBS_PY)' \
>  	  $(PYTHON_WORD) util/setup.py \
>  	  --quiet build_ext; \

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260520125637.105681-1-japo@linux.ibm.com?part=1

Re: [PATCH 1/1] perf build: Fix Python extension build with GCC 16 hardening

[Thomas Richter]

On 5/20/26 14:56, Jan Polensky wrote:
> The Python extension build fails with modern GCC versions (16+) due to
> the new hardening feature that prevents dynamic relocations in read-only
> segments:
> 
>   /usr/bin/ld.bfd: error: read-only segment has dynamic relocations
>   collect2: error: ld returned 1 exit status
> 
> This occurs when building the perf Python bindings because the linker
> enforces stricter security policies by default.
> 
> Add -Wl,-z,notext to LDSHARED to explicitly allow text relocations in
> the Python extension shared object. This is necessary for the Python
> C extension to link successfully while maintaining compatibility with
> the Python build system.
> 
> The flag only affects the Python extension build and does not impact
> the security of the main perf binary or other components.
> 
> Tested on Fedora 44 with GCC 16.1.1 20260501 (Red Hat 16.1.1-1) and
> Python 3.14.4 on s390x architecture.
> 
> Reported-by: Thomas Richter <tmricht@linux.ibm.com>
> Signed-off-by: Jan Polensky <japo@linux.ibm.com>
> ---
>  tools/perf/Makefile.perf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> index bfb37f527241..12af424dd5c1 100644
> --- a/tools/perf/Makefile.perf
> +++ b/tools/perf/Makefile.perf
> @@ -749,7 +749,7 @@ all: shell_compatibility_test $(ALL_PROGRAMS) $(LANG_BINDINGS) $(OTHER_PROGRAMS)
>  $(shell [ -d '$(OUTPUT)python' ] || mkdir -p '$(OUTPUT)python')
>  
>  $(OUTPUT)python/perf$(PYTHON_EXTENSION_SUFFIX): util/python.c util/setup.py $(PERFLIBS_PY)
> -	$(QUIET_GEN)LDSHARED="$(CC) -pthread -shared" \
> +	$(QUIET_GEN)LDSHARED="$(CC) -pthread -shared -Wl,-z,notext" \
>          CFLAGS='$(CFLAGS)' LDFLAGS='$(LDFLAGS) $(LIBS_PY)' \
>  	  $(PYTHON_WORD) util/setup.py \
>  	  --quiet build_ext; \

Thanks for fixing this.

Reviewed-by: Thomas Richter <tmricht@linux.ibm.com>
Tested-by: Thomas Richter <tmricht@linux.ibm.com>

-- 
Thomas Richter, Dept 3303, IBM s390 Linux Development, Boeblingen, Germany
--
IBM Deutschland Research & Development GmbH

Vorsitzender des Aufsichtsrats: Wolfgang Wendt

Geschäftsführung: David Faller

Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294

Re: [PATCH 1/1] perf build: Fix Python extension build with GCC 16 hardening

[Arnaldo Carvalho de Melo]

On Wed, May 20, 2026 at 01:09:05PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The patch explicitly allows text relocations in the Python extension shared object (`perf.so`) by adding `-Wl,-z,notext`, masking the root cause of missing `-fPIC` flags and breaking W^X (Write XOR Execute) security protections.
> --
> 
> commit f3832fb0ad0d1f9c2e69039b2a5110f77d220d5e
> Author: Jan Polensky <japo@linux.ibm.com>
> 
> perf build: Fix Python extension build with GCC 16 hardening
> 
> This commit addresses a build failure in the Python extension caused by GCC 16
> stricter security policies regarding dynamic relocations in read-only segments.
> It adds the -Wl,-z,notext flag to the linker to explicitly allow text
> relocations in the Python extension shared object.
> 
> > diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> > index 76b35ac19acbf..eea170d6576db 100644
> > --- a/tools/perf/Makefile.perf
> > +++ b/tools/perf/Makefile.perf
> > @@ -749,7 +749,7 @@ all: shell_compatibility_test $(ALL_PROGRAMS) $(LANG_BINDINGS) $(OTHER_PROGRAMS)
> >  $(shell [ -d '$(OUTPUT)python' ] || mkdir -p '$(OUTPUT)python')
> >  
> >  $(OUTPUT)python/perf$(PYTHON_EXTENSION_SUFFIX): util/python.c util/setup.py $(PERFLIBS_PY)
> > -	$(QUIET_GEN)LDSHARED="$(CC) -pthread -shared" \
> > +	$(QUIET_GEN)LDSHARED="$(CC) -pthread -shared -Wl,-z,notext" \
> 
> [Severity: Medium]
> Does adding -Wl,-z,notext mask the root cause of the GCC 16 linker error?
> 
> The error regarding dynamic relocations in a read-only segment usually
> indicates that non-position-independent code from the static libraries
> is being linked into the shared library.
> 
> Using -Wl,-z,notext suppresses this error by allowing text relocations, which
> forces the dynamic linker to map the executable text segment as writable at
> load time. This breaks W^X security protections and weakens the security of
> any Python process loading the extension.
> 
> Should the required object files be compiled with -fPIC instead to properly
> resolve the linker error without compromising security?

So I asked Claude about this and he suggests doing like other parts of
perf and using -fPIC, can you try to do that?

---------------------------------------

● Sashiko is right. -Wl,-z,notext is a band-aid that weakens security —
  it makes the text segment writable at load time, defeating W^X.

  The root cause is that PERFLIBS_PY (the static libraries linked into
  the Python .so) are compiled without -fPIC. When you link non-PIC .a
  archives into a shared library, the linker needs text relocations. GCC
  16 correctly rejects this by default.

  The proper fix is to build the static libraries that go into the
  Python extension with -fPIC. The perf build system already has
  precedent for this — look for how libperf and libsubcmd handle PIC
  builds. The Python extension's dependencies need a parallel -fPIC
  build, or the existing objects need to be compiled with -fPIC when the
  Python binding is enabled.

  The -Wl,-z,notext approach would also cause issues on distros that
  enforce RELRO + BIND_NOW hardening, and some package builders would
  reject the resulting .so outright.

- Arnaldo

Re: [PATCH 1/1] perf build: Fix Python extension build with GCC 16 hardening

[Jan Polensky]

On Sat, May 23, 2026 at 11:49:22PM -0300, Arnaldo Carvalho de Melo wrote:
> On Wed, May 20, 2026 at 01:09:05PM +0000, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > - [Medium] The patch explicitly allows text relocations in the Python extension shared object (`perf.so`) by adding `-Wl,-z,notext`, masking the root cause of missing `-fPIC` flags and breaking W^X (Write XOR Execute) security protections.
> > --
> >
> > commit f3832fb0ad0d1f9c2e69039b2a5110f77d220d5e
> > Author: Jan Polensky <japo@linux.ibm.com>
> >
> > perf build: Fix Python extension build with GCC 16 hardening
> >
> > This commit addresses a build failure in the Python extension caused by GCC 16
> > stricter security policies regarding dynamic relocations in read-only segments.
> > It adds the -Wl,-z,notext flag to the linker to explicitly allow text
> > relocations in the Python extension shared object.
> >
> > > diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> > > index 76b35ac19acbf..eea170d6576db 100644
> > > --- a/tools/perf/Makefile.perf
> > > +++ b/tools/perf/Makefile.perf
> > > @@ -749,7 +749,7 @@ all: shell_compatibility_test $(ALL_PROGRAMS) $(LANG_BINDINGS) $(OTHER_PROGRAMS)
> > >  $(shell [ -d '$(OUTPUT)python' ] || mkdir -p '$(OUTPUT)python')
> > >
> > >  $(OUTPUT)python/perf$(PYTHON_EXTENSION_SUFFIX): util/python.c util/setup.py $(PERFLIBS_PY)
> > > -	$(QUIET_GEN)LDSHARED="$(CC) -pthread -shared" \
> > > +	$(QUIET_GEN)LDSHARED="$(CC) -pthread -shared -Wl,-z,notext" \
> >
> > [Severity: Medium]
> > Does adding -Wl,-z,notext mask the root cause of the GCC 16 linker error?
> >
> > The error regarding dynamic relocations in a read-only segment usually
> > indicates that non-position-independent code from the static libraries
> > is being linked into the shared library.
> >
> > Using -Wl,-z,notext suppresses this error by allowing text relocations, which
> > forces the dynamic linker to map the executable text segment as writable at
> > load time. This breaks W^X security protections and weakens the security of
> > any Python process loading the extension.
> >
> > Should the required object files be compiled with -fPIC instead to properly
> > resolve the linker error without compromising security?
>
> So I asked Claude about this and he suggests doing like other parts of
> perf and using -fPIC, can you try to do that?
>
> ---------------------------------------
>
> ● Sashiko is right. -Wl,-z,notext is a band-aid that weakens security —
>   it makes the text segment writable at load time, defeating W^X.
>
>   The root cause is that PERFLIBS_PY (the static libraries linked into
>   the Python .so) are compiled without -fPIC. When you link non-PIC .a
>   archives into a shared library, the linker needs text relocations. GCC
>   16 correctly rejects this by default.
>
>   The proper fix is to build the static libraries that go into the
>   Python extension with -fPIC. The perf build system already has
>   precedent for this — look for how libperf and libsubcmd handle PIC
>   builds. The Python extension's dependencies need a parallel -fPIC
>   build, or the existing objects need to be compiled with -fPIC when the
>   Python binding is enabled.
>
>   The -Wl,-z,notext approach would also cause issues on distros that
>   enforce RELRO + BIND_NOW hardening, and some package builders would
>   reject the resulting .so outright.
>
> - Arnaldo

Hi Arnaldo,

thanks for the pointer. I double-checked this on s390x and did some reduced-link
testing for the ET_DYN / Python-extension case.

The failure is not triggered by the perf Python binding object alone.

A reduced reproducer succeeds when linking:
  python.o
  + libapi.a
  + libperf.a
  + libsubcmd.a
  + libsymbol.a
  + libbpf.a
  + libperf-ui.a

The link starts to fail with:
  /usr/bin/ld.bfd: error: read-only segment has dynamic relocations

as soon as libperf-util.a is added.

In my tree, libperf-util.a currently contains only perf-util-in.o, and replacing
the archive with that single object still reproduces the same failure.

Reduced reproducer:

  gcc -pthread -shared \
    -Wl,-z,noexecstack \
    -o /tmp/try-perf-util-only.so \
    /root/linux/tools/perf/python_ext_build/tmp/root/linux/tools/perf/util/python.o \
    -Wl,--whole-archive \
      /root/linux/tools/perf/libapi/libapi.a \
      /root/linux/tools/perf/libperf/libperf.a \
      /root/linux/tools/perf/libsubcmd/libsubcmd.a \
      /root/linux/tools/perf/libsymbol/libsymbol.a \
      /root/linux/tools/perf/libbpf/libbpf.a \
      /root/linux/tools/perf/libperf-ui.a \
    -Wl,--no-whole-archive \
    /root/perf-util-one/perf-util-in.o \
    -lpython3.14 -lpthread -ldl -lm -lutil

Inspection of perf-util-in.o on s390x shows many direct R_390_PC32DBL
relocations from .text against .data.rel.ro, .data.rel.ro.local,
.data.rel.local, .bss, and .rodata.

Representative examples include:

  arm64__associate_instruction_ops:
    larl %r6  -> R_390_PC32DBL .data.rel.ro+0x2

  loongarch__associate_ins_ops:
    larl %r9  -> R_390_PC32DBL .data.rel.ro+0x22
    larl %r9  -> R_390_PC32DBL .data.rel.ro+0x42

  check_ppc_insn:
    larl %r4  -> R_390_PC32DBL .data.rel.local+0x4c2
    larl %r2  -> R_390_PC32DBL .data.rel.ro.local+0x22
    larl %r1  -> R_390_PC32DBL .data.rel.local+0x2
    larl %r2  -> R_390_PC32DBL .data.rel.ro.local+0x2

  s390__associate_ins_ops:
    larl %r10 -> R_390_PC32DBL .data.rel.ro+0x732
    larl %r10 -> R_390_PC32DBL .data.rel.ro+0x752

So from my reproducer, I don't think we can describe this simply as
"all Python-extension dependency archives are missing -fPIC".

The issue narrows down much more specifically to perf-util-in.o in the ET_DYN
link of the Python extension, and the direct text-to-data section relocations
above look like the most relevant candidates.

So I agree that -Wl,-z,notext is only a workaround. I'd prefer to understand
and fix the underlying relocation pattern in perf-util-in.o rather than merge
that as-is.

If useful, I can send the relevant readelf/objdump snippets in a follow-up.

Best regards,
Jan

Re: [PATCH 1/1] perf build: Fix Python extension build with GCC 16 hardening

[Ian Rogers]

On Tue, May 26, 2026 at 3:35 AM Jan Polensky <japo@linux.ibm.com> wrote:
>
> On Sat, May 23, 2026 at 11:49:22PM -0300, Arnaldo Carvalho de Melo wrote:
> > On Wed, May 20, 2026 at 01:09:05PM +0000, sashiko-bot@kernel.org wrote:
> > > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > > - [Medium] The patch explicitly allows text relocations in the Python extension shared object (`perf.so`) by adding `-Wl,-z,notext`, masking the root cause of missing `-fPIC` flags and breaking W^X (Write XOR Execute) security protections.
> > > --
> > >
> > > commit f3832fb0ad0d1f9c2e69039b2a5110f77d220d5e
> > > Author: Jan Polensky <japo@linux.ibm.com>
> > >
> > > perf build: Fix Python extension build with GCC 16 hardening
> > >
> > > This commit addresses a build failure in the Python extension caused by GCC 16
> > > stricter security policies regarding dynamic relocations in read-only segments.
> > > It adds the -Wl,-z,notext flag to the linker to explicitly allow text
> > > relocations in the Python extension shared object.
> > >
> > > > diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> > > > index 76b35ac19acbf..eea170d6576db 100644
> > > > --- a/tools/perf/Makefile.perf
> > > > +++ b/tools/perf/Makefile.perf
> > > > @@ -749,7 +749,7 @@ all: shell_compatibility_test $(ALL_PROGRAMS) $(LANG_BINDINGS) $(OTHER_PROGRAMS)
> > > >  $(shell [ -d '$(OUTPUT)python' ] || mkdir -p '$(OUTPUT)python')
> > > >
> > > >  $(OUTPUT)python/perf$(PYTHON_EXTENSION_SUFFIX): util/python.c util/setup.py $(PERFLIBS_PY)
> > > > - $(QUIET_GEN)LDSHARED="$(CC) -pthread -shared" \
> > > > + $(QUIET_GEN)LDSHARED="$(CC) -pthread -shared -Wl,-z,notext" \
> > >
> > > [Severity: Medium]
> > > Does adding -Wl,-z,notext mask the root cause of the GCC 16 linker error?
> > >
> > > The error regarding dynamic relocations in a read-only segment usually
> > > indicates that non-position-independent code from the static libraries
> > > is being linked into the shared library.
> > >
> > > Using -Wl,-z,notext suppresses this error by allowing text relocations, which
> > > forces the dynamic linker to map the executable text segment as writable at
> > > load time. This breaks W^X security protections and weakens the security of
> > > any Python process loading the extension.
> > >
> > > Should the required object files be compiled with -fPIC instead to properly
> > > resolve the linker error without compromising security?
> >
> > So I asked Claude about this and he suggests doing like other parts of
> > perf and using -fPIC, can you try to do that?
> >
> > ---------------------------------------
> >
> > ● Sashiko is right. -Wl,-z,notext is a band-aid that weakens security —
> >   it makes the text segment writable at load time, defeating W^X.
> >
> >   The root cause is that PERFLIBS_PY (the static libraries linked into
> >   the Python .so) are compiled without -fPIC. When you link non-PIC .a
> >   archives into a shared library, the linker needs text relocations. GCC
> >   16 correctly rejects this by default.
> >
> >   The proper fix is to build the static libraries that go into the
> >   Python extension with -fPIC. The perf build system already has
> >   precedent for this — look for how libperf and libsubcmd handle PIC
> >   builds. The Python extension's dependencies need a parallel -fPIC
> >   build, or the existing objects need to be compiled with -fPIC when the
> >   Python binding is enabled.
> >
> >   The -Wl,-z,notext approach would also cause issues on distros that
> >   enforce RELRO + BIND_NOW hardening, and some package builders would
> >   reject the resulting .so outright.
> >
> > - Arnaldo
>
> Hi Arnaldo,
>
> thanks for the pointer. I double-checked this on s390x and did some reduced-link
> testing for the ET_DYN / Python-extension case.
>
> The failure is not triggered by the perf Python binding object alone.
>
> A reduced reproducer succeeds when linking:
>   python.o
>   + libapi.a
>   + libperf.a
>   + libsubcmd.a
>   + libsymbol.a
>   + libbpf.a
>   + libperf-ui.a
>
> The link starts to fail with:
>   /usr/bin/ld.bfd: error: read-only segment has dynamic relocations
>
> as soon as libperf-util.a is added.
>
> In my tree, libperf-util.a currently contains only perf-util-in.o, and replacing
> the archive with that single object still reproduces the same failure.
>
> Reduced reproducer:
>
>   gcc -pthread -shared \
>     -Wl,-z,noexecstack \
>     -o /tmp/try-perf-util-only.so \
>     /root/linux/tools/perf/python_ext_build/tmp/root/linux/tools/perf/util/python.o \
>     -Wl,--whole-archive \
>       /root/linux/tools/perf/libapi/libapi.a \
>       /root/linux/tools/perf/libperf/libperf.a \
>       /root/linux/tools/perf/libsubcmd/libsubcmd.a \
>       /root/linux/tools/perf/libsymbol/libsymbol.a \
>       /root/linux/tools/perf/libbpf/libbpf.a \
>       /root/linux/tools/perf/libperf-ui.a \
>     -Wl,--no-whole-archive \
>     /root/perf-util-one/perf-util-in.o \
>     -lpython3.14 -lpthread -ldl -lm -lutil
>
> Inspection of perf-util-in.o on s390x shows many direct R_390_PC32DBL
> relocations from .text against .data.rel.ro, .data.rel.ro.local,
> .data.rel.local, .bss, and .rodata.
>
> Representative examples include:
>
>   arm64__associate_instruction_ops:
>     larl %r6  -> R_390_PC32DBL .data.rel.ro+0x2
>
>   loongarch__associate_ins_ops:
>     larl %r9  -> R_390_PC32DBL .data.rel.ro+0x22
>     larl %r9  -> R_390_PC32DBL .data.rel.ro+0x42
>
>   check_ppc_insn:
>     larl %r4  -> R_390_PC32DBL .data.rel.local+0x4c2
>     larl %r2  -> R_390_PC32DBL .data.rel.ro.local+0x22
>     larl %r1  -> R_390_PC32DBL .data.rel.local+0x2
>     larl %r2  -> R_390_PC32DBL .data.rel.ro.local+0x2
>
>   s390__associate_ins_ops:
>     larl %r10 -> R_390_PC32DBL .data.rel.ro+0x732
>     larl %r10 -> R_390_PC32DBL .data.rel.ro+0x752
>
> So from my reproducer, I don't think we can describe this simply as
> "all Python-extension dependency archives are missing -fPIC".
>
> The issue narrows down much more specifically to perf-util-in.o in the ET_DYN
> link of the Python extension, and the direct text-to-data section relocations
> above look like the most relevant candidates.
>
> So I agree that -Wl,-z,notext is only a workaround. I'd prefer to understand
> and fix the underlying relocation pattern in perf-util-in.o rather than merge
> that as-is.
>
> If useful, I can send the relevant readelf/objdump snippets in a follow-up.

Hi Jan,

I wonder about two tests:
1) adding V=1 JOBS=1 to your make command to switch on single
threading and build verbosity. This may make it possible to identify
the gcc command that is missing -fPIC. For example, I see -fPIC on
x86:
  gcc -Wp,-MD,/tmp/perf4/util/annotate-arch/.annotate-arm64.o.d
-Wp,-MT,/tmp/perf4/util/annotate-arch/annotate -arm64.o
-Wbad-function-cast -Wdeclaration-after-statement -Wformat-security
-Wformat-y2k -Winit-self -Wmissin g-declarations -Wmissing-prototypes
-Wno-system-headers -Wold-style-definition -Wpacked -Wredundant-decls
-Wst rict-prototypes -Wswitch-default -Wswitch-enum -Wundef
-Wwrite-strings -Wformat -Wno-type-limits -Wstrict-alia sing=3
-Wshadow -fno-strict-aliasing -I/tmp/perf4/arch/x86/include/generated
-DHAVE_ARCH_X86_64_SUPPORT -Werro r -g -fno-omit-frame-pointer -Wall
-Wextra -std=gnu11 -funsigned-char -fstack-protector-all
-D_LARGEFILE64_SOU RCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
-I~/linux/tools/perf/util/include
-I~/linux/tools/perf/arch/x86/include
-I/usr/local/google/home/irogers/re pos/linux4/tools/include/
-I~/linux/tools/arch/x86/include/uapi -I/usr/loc
al/google/home/irogers/repos/linux4/tools/include/uapi
-I~/linux/tools/arc h/x86/include/ -I~/linux/tools/arch/x86/
-I/tmp/perf4//util -I/tmp/perf4/ -I~/linux/tools/perf/util
-I~/linux/to ols/perf -DHAVE_PTHREAD_ATTR_SETAFFINITY_NP
-DHAVE_PTHREAD_BARRIER -DHAVE_EVENTFD_SUPPORT -DHAVE_GETTID -DHAVE
_FILE_HANDLE -DHAVE_AIO_SUPPORT -DHAVE_SCANDIRAT_SUPPORT
-DHAVE_SCHED_GETCPU_SUPPORT -DHAVE_SETNS_SUPPORT -DHA VE_ZLIB_SUPPORT
-DHAVE_LIBELF_SUPPORT -DHAVE_ELF_GETPHDRNUM_SUPPORT
-DHAVE_GELF_GETNOTE_SUPPORT -DHAVE_ELF_GET SHDRSTRNDX_SUPPORT
-DHAVE_DEBUGINFOD_SUPPORT -DHAVE_LIBDW_SUPPORT -DHAVE_LIBBPF_SUPPORT
-DHAVE_SDT_EVENT -DHAV E_JITDUMP -DHAVE_LIBOPENSSL_SUPPORT
-DHAVE_BPF_SKEL -DHAVE_DWARF_UNWIND_SUPPORT -DHAVE_SLANG_SUPPORT
-DHAVE_TI MERFD_SUPPORT -fPIC -DHAVE_LIBLLVM_SUPPORT
-I/usr/lib/llvm-19/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-DHAVE_CXA_DEMANGLE_SUPPORT -DHAVE_LZMA_SUPPORT -DHAVE_ZSTD_SUPPORT
-DHAVE_BACKTRACE_SUPPORT -DHAVE_LIBNUMA_SUPPORT
-DHAVE_PERF_READ_VDSO32 -DHAVE_LIBBABELTRACE_SUPPORT -DHAVE_
LIBCAPSTONE_SUPPORT -DHAVE_JVMTI_CMLR -DHAVE_LIBPFM
-DHAVE_LIBTRACEEVENT -I/usr/include/traceevent -DLIBTRACEE
VENT_VERSION=67072 -DHAVE_RUST_SUPPORT -I/tmp/perf4/libapi/include
-I/tmp/perf4/libbpf/include -I/tmp/perf4/li bsubcmd/include
-I/tmp/perf4/libsymbol/include -I/tmp/perf4/libperf/include
-I/tmp/perf4/ -D"BUILD_STR(s)=#s" -c -o
/tmp/perf4/util/annotate-arch/annotate-arm64.o
util/annotate-arch/annotate-arm64.c

2) adding EXTRA_CFLAGS="-fPIC" to your make command. This should force
this option wherever it might be missing.

Thanks,
Ian

> Best regards,
> Jan
>

Re: [PATCH 1/1] perf build: Fix Python extension build with GCC 16 hardening

[Jan Polensky]

On Tue, May 26, 2026 at 08:23:28AM -0700, Ian Rogers wrote:
> On Tue, May 26, 2026 at 3:35 AM Jan Polensky <japo@linux.ibm.com> wrote:
> >
> > On Sat, May 23, 2026 at 11:49:22PM -0300, Arnaldo Carvalho de Melo wrote:
> > > On Wed, May 20, 2026 at 01:09:05PM +0000, sashiko-bot@kernel.org wrote:
> > > > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > > > - [Medium] The patch explicitly allows text relocations in the Python extension shared object (`perf.so`) by adding `-Wl,-z,notext`, masking the root cause of missing `-fPIC` flags and breaking W^X (Write XOR Execute) security protections.
> > > > --
> > > >
> > > > commit f3832fb0ad0d1f9c2e69039b2a5110f77d220d5e
> > > > Author: Jan Polensky <japo@linux.ibm.com>
> > > >
> > > > perf build: Fix Python extension build with GCC 16 hardening
> > > >
> > > > This commit addresses a build failure in the Python extension caused by GCC 16
> > > > stricter security policies regarding dynamic relocations in read-only segments.
> > > > It adds the -Wl,-z,notext flag to the linker to explicitly allow text
> > > > relocations in the Python extension shared object.
> > > >
> > > > > diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> > > > > index 76b35ac19acbf..eea170d6576db 100644
> > > > > --- a/tools/perf/Makefile.perf
> > > > > +++ b/tools/perf/Makefile.perf
> > > > > @@ -749,7 +749,7 @@ all: shell_compatibility_test $(ALL_PROGRAMS) $(LANG_BINDINGS) $(OTHER_PROGRAMS)
> > > > >  $(shell [ -d '$(OUTPUT)python' ] || mkdir -p '$(OUTPUT)python')
> > > > >
> > > > >  $(OUTPUT)python/perf$(PYTHON_EXTENSION_SUFFIX): util/python.c util/setup.py $(PERFLIBS_PY)
> > > > > - $(QUIET_GEN)LDSHARED="$(CC) -pthread -shared" \
> > > > > + $(QUIET_GEN)LDSHARED="$(CC) -pthread -shared -Wl,-z,notext" \
> > > >
> > > > [Severity: Medium]
> > > > Does adding -Wl,-z,notext mask the root cause of the GCC 16 linker error?
> > > >
> > > > The error regarding dynamic relocations in a read-only segment usually
> > > > indicates that non-position-independent code from the static libraries
> > > > is being linked into the shared library.
> > > >
> > > > Using -Wl,-z,notext suppresses this error by allowing text relocations, which
> > > > forces the dynamic linker to map the executable text segment as writable at
> > > > load time. This breaks W^X security protections and weakens the security of
> > > > any Python process loading the extension.
> > > >
> > > > Should the required object files be compiled with -fPIC instead to properly
> > > > resolve the linker error without compromising security?
> > >
> > > So I asked Claude about this and he suggests doing like other parts of
> > > perf and using -fPIC, can you try to do that?
> > >
> > > ---------------------------------------
> > >
> > > ● Sashiko is right. -Wl,-z,notext is a band-aid that weakens security —
> > >   it makes the text segment writable at load time, defeating W^X.
> > >
> > >   The root cause is that PERFLIBS_PY (the static libraries linked into
> > >   the Python .so) are compiled without -fPIC. When you link non-PIC .a
> > >   archives into a shared library, the linker needs text relocations. GCC
> > >   16 correctly rejects this by default.
> > >
> > >   The proper fix is to build the static libraries that go into the
> > >   Python extension with -fPIC. The perf build system already has
> > >   precedent for this — look for how libperf and libsubcmd handle PIC
> > >   builds. The Python extension's dependencies need a parallel -fPIC
> > >   build, or the existing objects need to be compiled with -fPIC when the
> > >   Python binding is enabled.
> > >
> > >   The -Wl,-z,notext approach would also cause issues on distros that
> > >   enforce RELRO + BIND_NOW hardening, and some package builders would
> > >   reject the resulting .so outright.
> > >
> > > - Arnaldo
> >
> > Hi Arnaldo,
> >
> > thanks for the pointer. I double-checked this on s390x and did some reduced-link
> > testing for the ET_DYN / Python-extension case.
> >
> > The failure is not triggered by the perf Python binding object alone.
> >
> > A reduced reproducer succeeds when linking:
> >   python.o
> >   + libapi.a
> >   + libperf.a
> >   + libsubcmd.a
> >   + libsymbol.a
> >   + libbpf.a
> >   + libperf-ui.a
> >
> > The link starts to fail with:
> >   /usr/bin/ld.bfd: error: read-only segment has dynamic relocations
> >
> > as soon as libperf-util.a is added.
> >
> > In my tree, libperf-util.a currently contains only perf-util-in.o, and replacing
> > the archive with that single object still reproduces the same failure.
> >
> > Reduced reproducer:
> >
> >   gcc -pthread -shared \
> >     -Wl,-z,noexecstack \
> >     -o /tmp/try-perf-util-only.so \
> >     /root/linux/tools/perf/python_ext_build/tmp/root/linux/tools/perf/util/python.o \
> >     -Wl,--whole-archive \
> >       /root/linux/tools/perf/libapi/libapi.a \
> >       /root/linux/tools/perf/libperf/libperf.a \
> >       /root/linux/tools/perf/libsubcmd/libsubcmd.a \
> >       /root/linux/tools/perf/libsymbol/libsymbol.a \
> >       /root/linux/tools/perf/libbpf/libbpf.a \
> >       /root/linux/tools/perf/libperf-ui.a \
> >     -Wl,--no-whole-archive \
> >     /root/perf-util-one/perf-util-in.o \
> >     -lpython3.14 -lpthread -ldl -lm -lutil
> >
> > Inspection of perf-util-in.o on s390x shows many direct R_390_PC32DBL
> > relocations from .text against .data.rel.ro, .data.rel.ro.local,
> > .data.rel.local, .bss, and .rodata.
> >
> > Representative examples include:
> >
> >   arm64__associate_instruction_ops:
> >     larl %r6  -> R_390_PC32DBL .data.rel.ro+0x2
> >
> >   loongarch__associate_ins_ops:
> >     larl %r9  -> R_390_PC32DBL .data.rel.ro+0x22
> >     larl %r9  -> R_390_PC32DBL .data.rel.ro+0x42
> >
> >   check_ppc_insn:
> >     larl %r4  -> R_390_PC32DBL .data.rel.local+0x4c2
> >     larl %r2  -> R_390_PC32DBL .data.rel.ro.local+0x22
> >     larl %r1  -> R_390_PC32DBL .data.rel.local+0x2
> >     larl %r2  -> R_390_PC32DBL .data.rel.ro.local+0x2
> >
> >   s390__associate_ins_ops:
> >     larl %r10 -> R_390_PC32DBL .data.rel.ro+0x732
> >     larl %r10 -> R_390_PC32DBL .data.rel.ro+0x752
> >
> > So from my reproducer, I don't think we can describe this simply as
> > "all Python-extension dependency archives are missing -fPIC".
> >
> > The issue narrows down much more specifically to perf-util-in.o in the ET_DYN
> > link of the Python extension, and the direct text-to-data section relocations
> > above look like the most relevant candidates.
> >
> > So I agree that -Wl,-z,notext is only a workaround. I'd prefer to understand
> > and fix the underlying relocation pattern in perf-util-in.o rather than merge
> > that as-is.
> >
> > If useful, I can send the relevant readelf/objdump snippets in a follow-up.
>
> Hi Jan,
>
> I wonder about two tests:
> 1) adding V=1 JOBS=1 to your make command to switch on single
> threading and build verbosity. This may make it possible to identify
> the gcc command that is missing -fPIC. For example, I see -fPIC on
> x86:
>   gcc -Wp,-MD,/tmp/perf4/util/annotate-arch/.annotate-arm64.o.d
> -Wp,-MT,/tmp/perf4/util/annotate-arch/annotate -arm64.o
> -Wbad-function-cast -Wdeclaration-after-statement -Wformat-security
> -Wformat-y2k -Winit-self -Wmissin g-declarations -Wmissing-prototypes
> -Wno-system-headers -Wold-style-definition -Wpacked -Wredundant-decls
> -Wst rict-prototypes -Wswitch-default -Wswitch-enum -Wundef
> -Wwrite-strings -Wformat -Wno-type-limits -Wstrict-alia sing=3
> -Wshadow -fno-strict-aliasing -I/tmp/perf4/arch/x86/include/generated
> -DHAVE_ARCH_X86_64_SUPPORT -Werro r -g -fno-omit-frame-pointer -Wall
> -Wextra -std=gnu11 -funsigned-char -fstack-protector-all
> -D_LARGEFILE64_SOU RCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
> -I~/linux/tools/perf/util/include
> -I~/linux/tools/perf/arch/x86/include
> -I/usr/local/google/home/irogers/re pos/linux4/tools/include/
> -I~/linux/tools/arch/x86/include/uapi -I/usr/loc
> al/google/home/irogers/repos/linux4/tools/include/uapi
> -I~/linux/tools/arc h/x86/include/ -I~/linux/tools/arch/x86/
> -I/tmp/perf4//util -I/tmp/perf4/ -I~/linux/tools/perf/util
> -I~/linux/to ols/perf -DHAVE_PTHREAD_ATTR_SETAFFINITY_NP
> -DHAVE_PTHREAD_BARRIER -DHAVE_EVENTFD_SUPPORT -DHAVE_GETTID -DHAVE
> _FILE_HANDLE -DHAVE_AIO_SUPPORT -DHAVE_SCANDIRAT_SUPPORT
> -DHAVE_SCHED_GETCPU_SUPPORT -DHAVE_SETNS_SUPPORT -DHA VE_ZLIB_SUPPORT
> -DHAVE_LIBELF_SUPPORT -DHAVE_ELF_GETPHDRNUM_SUPPORT
> -DHAVE_GELF_GETNOTE_SUPPORT -DHAVE_ELF_GET SHDRSTRNDX_SUPPORT
> -DHAVE_DEBUGINFOD_SUPPORT -DHAVE_LIBDW_SUPPORT -DHAVE_LIBBPF_SUPPORT
> -DHAVE_SDT_EVENT -DHAV E_JITDUMP -DHAVE_LIBOPENSSL_SUPPORT
> -DHAVE_BPF_SKEL -DHAVE_DWARF_UNWIND_SUPPORT -DHAVE_SLANG_SUPPORT
> -DHAVE_TI MERFD_SUPPORT -fPIC -DHAVE_LIBLLVM_SUPPORT
> -I/usr/lib/llvm-19/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> -DHAVE_CXA_DEMANGLE_SUPPORT -DHAVE_LZMA_SUPPORT -DHAVE_ZSTD_SUPPORT
> -DHAVE_BACKTRACE_SUPPORT -DHAVE_LIBNUMA_SUPPORT
> -DHAVE_PERF_READ_VDSO32 -DHAVE_LIBBABELTRACE_SUPPORT -DHAVE_
> LIBCAPSTONE_SUPPORT -DHAVE_JVMTI_CMLR -DHAVE_LIBPFM
> -DHAVE_LIBTRACEEVENT -I/usr/include/traceevent -DLIBTRACEE
> VENT_VERSION=67072 -DHAVE_RUST_SUPPORT -I/tmp/perf4/libapi/include
> -I/tmp/perf4/libbpf/include -I/tmp/perf4/li bsubcmd/include
> -I/tmp/perf4/libsymbol/include -I/tmp/perf4/libperf/include
> -I/tmp/perf4/ -D"BUILD_STR(s)=#s" -c -o
> /tmp/perf4/util/annotate-arch/annotate-arm64.o
> util/annotate-arch/annotate-arm64.c
>
> 2) adding EXTRA_CFLAGS="-fPIC" to your make command. This should force
> this option wherever it might be missing.
>
> Thanks,
> Ian
>
> > Best regards,
> > Jan
> >
Hi Ian,

I tested both suggestions the second in the beginning of my research:

EXTRA_CFLAGS="-fPIC" - Does NOT work. Same error:

/usr/bin/ld.bfd: error: read-only segment has dynamic relocations
collect2: error: ld returned 1 exit status

The issue is s390x-specific R_390_PC32DBL relocations in perf-util-in.o
(from `larl` instructions) that persist even with -fPIC.

Current options:
1. Use -Wl,-z,notext (security issue)
2. Refactor code to avoid these relocations
3. Disable Python extension on s390x (not an option)

Thoughts?

Best regards,
Jan

Re: [PATCH 1/1] perf build: Fix Python extension build with GCC 16 hardening

[Ian Rogers]

On Tue, May 26, 2026 at 9:20 AM Jan Polensky <japo@linux.ibm.com> wrote:
>
> On Tue, May 26, 2026 at 08:23:28AM -0700, Ian Rogers wrote:
> > On Tue, May 26, 2026 at 3:35 AM Jan Polensky <japo@linux.ibm.com> wrote:
> > >
> > > On Sat, May 23, 2026 at 11:49:22PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > On Wed, May 20, 2026 at 01:09:05PM +0000, sashiko-bot@kernel.org wrote:
> > > > > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > > > > - [Medium] The patch explicitly allows text relocations in the Python extension shared object (`perf.so`) by adding `-Wl,-z,notext`, masking the root cause of missing `-fPIC` flags and breaking W^X (Write XOR Execute) security protections.
> > > > > --
> > > > >
> > > > > commit f3832fb0ad0d1f9c2e69039b2a5110f77d220d5e
> > > > > Author: Jan Polensky <japo@linux.ibm.com>
> > > > >
> > > > > perf build: Fix Python extension build with GCC 16 hardening
> > > > >
> > > > > This commit addresses a build failure in the Python extension caused by GCC 16
> > > > > stricter security policies regarding dynamic relocations in read-only segments.
> > > > > It adds the -Wl,-z,notext flag to the linker to explicitly allow text
> > > > > relocations in the Python extension shared object.
> > > > >
> > > > > > diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> > > > > > index 76b35ac19acbf..eea170d6576db 100644
> > > > > > --- a/tools/perf/Makefile.perf
> > > > > > +++ b/tools/perf/Makefile.perf
> > > > > > @@ -749,7 +749,7 @@ all: shell_compatibility_test $(ALL_PROGRAMS) $(LANG_BINDINGS) $(OTHER_PROGRAMS)
> > > > > >  $(shell [ -d '$(OUTPUT)python' ] || mkdir -p '$(OUTPUT)python')
> > > > > >
> > > > > >  $(OUTPUT)python/perf$(PYTHON_EXTENSION_SUFFIX): util/python.c util/setup.py $(PERFLIBS_PY)
> > > > > > - $(QUIET_GEN)LDSHARED="$(CC) -pthread -shared" \
> > > > > > + $(QUIET_GEN)LDSHARED="$(CC) -pthread -shared -Wl,-z,notext" \
> > > > >
> > > > > [Severity: Medium]
> > > > > Does adding -Wl,-z,notext mask the root cause of the GCC 16 linker error?
> > > > >
> > > > > The error regarding dynamic relocations in a read-only segment usually
> > > > > indicates that non-position-independent code from the static libraries
> > > > > is being linked into the shared library.
> > > > >
> > > > > Using -Wl,-z,notext suppresses this error by allowing text relocations, which
> > > > > forces the dynamic linker to map the executable text segment as writable at
> > > > > load time. This breaks W^X security protections and weakens the security of
> > > > > any Python process loading the extension.
> > > > >
> > > > > Should the required object files be compiled with -fPIC instead to properly
> > > > > resolve the linker error without compromising security?
> > > >
> > > > So I asked Claude about this and he suggests doing like other parts of
> > > > perf and using -fPIC, can you try to do that?
> > > >
> > > > ---------------------------------------
> > > >
> > > > ● Sashiko is right. -Wl,-z,notext is a band-aid that weakens security —
> > > >   it makes the text segment writable at load time, defeating W^X.
> > > >
> > > >   The root cause is that PERFLIBS_PY (the static libraries linked into
> > > >   the Python .so) are compiled without -fPIC. When you link non-PIC .a
> > > >   archives into a shared library, the linker needs text relocations. GCC
> > > >   16 correctly rejects this by default.
> > > >
> > > >   The proper fix is to build the static libraries that go into the
> > > >   Python extension with -fPIC. The perf build system already has
> > > >   precedent for this — look for how libperf and libsubcmd handle PIC
> > > >   builds. The Python extension's dependencies need a parallel -fPIC
> > > >   build, or the existing objects need to be compiled with -fPIC when the
> > > >   Python binding is enabled.
> > > >
> > > >   The -Wl,-z,notext approach would also cause issues on distros that
> > > >   enforce RELRO + BIND_NOW hardening, and some package builders would
> > > >   reject the resulting .so outright.
> > > >
> > > > - Arnaldo
> > >
> > > Hi Arnaldo,
> > >
> > > thanks for the pointer. I double-checked this on s390x and did some reduced-link
> > > testing for the ET_DYN / Python-extension case.
> > >
> > > The failure is not triggered by the perf Python binding object alone.
> > >
> > > A reduced reproducer succeeds when linking:
> > >   python.o
> > >   + libapi.a
> > >   + libperf.a
> > >   + libsubcmd.a
> > >   + libsymbol.a
> > >   + libbpf.a
> > >   + libperf-ui.a
> > >
> > > The link starts to fail with:
> > >   /usr/bin/ld.bfd: error: read-only segment has dynamic relocations
> > >
> > > as soon as libperf-util.a is added.
> > >
> > > In my tree, libperf-util.a currently contains only perf-util-in.o, and replacing
> > > the archive with that single object still reproduces the same failure.
> > >
> > > Reduced reproducer:
> > >
> > >   gcc -pthread -shared \
> > >     -Wl,-z,noexecstack \
> > >     -o /tmp/try-perf-util-only.so \
> > >     /root/linux/tools/perf/python_ext_build/tmp/root/linux/tools/perf/util/python.o \
> > >     -Wl,--whole-archive \
> > >       /root/linux/tools/perf/libapi/libapi.a \
> > >       /root/linux/tools/perf/libperf/libperf.a \
> > >       /root/linux/tools/perf/libsubcmd/libsubcmd.a \
> > >       /root/linux/tools/perf/libsymbol/libsymbol.a \
> > >       /root/linux/tools/perf/libbpf/libbpf.a \
> > >       /root/linux/tools/perf/libperf-ui.a \
> > >     -Wl,--no-whole-archive \
> > >     /root/perf-util-one/perf-util-in.o \
> > >     -lpython3.14 -lpthread -ldl -lm -lutil
> > >
> > > Inspection of perf-util-in.o on s390x shows many direct R_390_PC32DBL
> > > relocations from .text against .data.rel.ro, .data.rel.ro.local,
> > > .data.rel.local, .bss, and .rodata.
> > >
> > > Representative examples include:
> > >
> > >   arm64__associate_instruction_ops:
> > >     larl %r6  -> R_390_PC32DBL .data.rel.ro+0x2
> > >
> > >   loongarch__associate_ins_ops:
> > >     larl %r9  -> R_390_PC32DBL .data.rel.ro+0x22
> > >     larl %r9  -> R_390_PC32DBL .data.rel.ro+0x42
> > >
> > >   check_ppc_insn:
> > >     larl %r4  -> R_390_PC32DBL .data.rel.local+0x4c2
> > >     larl %r2  -> R_390_PC32DBL .data.rel.ro.local+0x22
> > >     larl %r1  -> R_390_PC32DBL .data.rel.local+0x2
> > >     larl %r2  -> R_390_PC32DBL .data.rel.ro.local+0x2
> > >
> > >   s390__associate_ins_ops:
> > >     larl %r10 -> R_390_PC32DBL .data.rel.ro+0x732
> > >     larl %r10 -> R_390_PC32DBL .data.rel.ro+0x752
> > >
> > > So from my reproducer, I don't think we can describe this simply as
> > > "all Python-extension dependency archives are missing -fPIC".
> > >
> > > The issue narrows down much more specifically to perf-util-in.o in the ET_DYN
> > > link of the Python extension, and the direct text-to-data section relocations
> > > above look like the most relevant candidates.
> > >
> > > So I agree that -Wl,-z,notext is only a workaround. I'd prefer to understand
> > > and fix the underlying relocation pattern in perf-util-in.o rather than merge
> > > that as-is.
> > >
> > > If useful, I can send the relevant readelf/objdump snippets in a follow-up.
> >
> > Hi Jan,
> >
> > I wonder about two tests:
> > 1) adding V=1 JOBS=1 to your make command to switch on single
> > threading and build verbosity. This may make it possible to identify
> > the gcc command that is missing -fPIC. For example, I see -fPIC on
> > x86:
> >   gcc -Wp,-MD,/tmp/perf4/util/annotate-arch/.annotate-arm64.o.d
> > -Wp,-MT,/tmp/perf4/util/annotate-arch/annotate -arm64.o
> > -Wbad-function-cast -Wdeclaration-after-statement -Wformat-security
> > -Wformat-y2k -Winit-self -Wmissin g-declarations -Wmissing-prototypes
> > -Wno-system-headers -Wold-style-definition -Wpacked -Wredundant-decls
> > -Wst rict-prototypes -Wswitch-default -Wswitch-enum -Wundef
> > -Wwrite-strings -Wformat -Wno-type-limits -Wstrict-alia sing=3
> > -Wshadow -fno-strict-aliasing -I/tmp/perf4/arch/x86/include/generated
> > -DHAVE_ARCH_X86_64_SUPPORT -Werro r -g -fno-omit-frame-pointer -Wall
> > -Wextra -std=gnu11 -funsigned-char -fstack-protector-all
> > -D_LARGEFILE64_SOU RCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
> > -I~/linux/tools/perf/util/include
> > -I~/linux/tools/perf/arch/x86/include
> > -I/usr/local/google/home/irogers/re pos/linux4/tools/include/
> > -I~/linux/tools/arch/x86/include/uapi -I/usr/loc
> > al/google/home/irogers/repos/linux4/tools/include/uapi
> > -I~/linux/tools/arc h/x86/include/ -I~/linux/tools/arch/x86/
> > -I/tmp/perf4//util -I/tmp/perf4/ -I~/linux/tools/perf/util
> > -I~/linux/to ols/perf -DHAVE_PTHREAD_ATTR_SETAFFINITY_NP
> > -DHAVE_PTHREAD_BARRIER -DHAVE_EVENTFD_SUPPORT -DHAVE_GETTID -DHAVE
> > _FILE_HANDLE -DHAVE_AIO_SUPPORT -DHAVE_SCANDIRAT_SUPPORT
> > -DHAVE_SCHED_GETCPU_SUPPORT -DHAVE_SETNS_SUPPORT -DHA VE_ZLIB_SUPPORT
> > -DHAVE_LIBELF_SUPPORT -DHAVE_ELF_GETPHDRNUM_SUPPORT
> > -DHAVE_GELF_GETNOTE_SUPPORT -DHAVE_ELF_GET SHDRSTRNDX_SUPPORT
> > -DHAVE_DEBUGINFOD_SUPPORT -DHAVE_LIBDW_SUPPORT -DHAVE_LIBBPF_SUPPORT
> > -DHAVE_SDT_EVENT -DHAV E_JITDUMP -DHAVE_LIBOPENSSL_SUPPORT
> > -DHAVE_BPF_SKEL -DHAVE_DWARF_UNWIND_SUPPORT -DHAVE_SLANG_SUPPORT
> > -DHAVE_TI MERFD_SUPPORT -fPIC -DHAVE_LIBLLVM_SUPPORT
> > -I/usr/lib/llvm-19/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
> > -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> > -DHAVE_CXA_DEMANGLE_SUPPORT -DHAVE_LZMA_SUPPORT -DHAVE_ZSTD_SUPPORT
> > -DHAVE_BACKTRACE_SUPPORT -DHAVE_LIBNUMA_SUPPORT
> > -DHAVE_PERF_READ_VDSO32 -DHAVE_LIBBABELTRACE_SUPPORT -DHAVE_
> > LIBCAPSTONE_SUPPORT -DHAVE_JVMTI_CMLR -DHAVE_LIBPFM
> > -DHAVE_LIBTRACEEVENT -I/usr/include/traceevent -DLIBTRACEE
> > VENT_VERSION=67072 -DHAVE_RUST_SUPPORT -I/tmp/perf4/libapi/include
> > -I/tmp/perf4/libbpf/include -I/tmp/perf4/li bsubcmd/include
> > -I/tmp/perf4/libsymbol/include -I/tmp/perf4/libperf/include
> > -I/tmp/perf4/ -D"BUILD_STR(s)=#s" -c -o
> > /tmp/perf4/util/annotate-arch/annotate-arm64.o
> > util/annotate-arch/annotate-arm64.c
> >
> > 2) adding EXTRA_CFLAGS="-fPIC" to your make command. This should force
> > this option wherever it might be missing.
> >
> > Thanks,
> > Ian
> >
> > > Best regards,
> > > Jan
> > >
> Hi Ian,
>
> I tested both suggestions the second in the beginning of my research:
>
> EXTRA_CFLAGS="-fPIC" - Does NOT work. Same error:
>
> /usr/bin/ld.bfd: error: read-only segment has dynamic relocations
> collect2: error: ld returned 1 exit status
>
> The issue is s390x-specific R_390_PC32DBL relocations in perf-util-in.o
> (from `larl` instructions) that persist even with -fPIC.
>
> Current options:
> 1. Use -Wl,-z,notext (security issue)
> 2. Refactor code to avoid these relocations
> 3. Disable Python extension on s390x (not an option)
>
> Thoughts?

So it appears that part of the problem is declaring arrays and structs
to be const. Making things non-const I think is also not an option.
Would  EXTRA_CFLAGS="-fvisibility=hidden" help?

It would we interesting to build with -Wl,-z,notext and then look for
the symbol the linker is fighting with:
  eu-findtextrel perf.cpython....so
or
  readelf -d perf.so | grep TEXTREL
  readelf -r perf.so

Thanks,
Ian

> Best regards,
> Jan

Re: [PATCH 1/1] perf build: Fix Python extension build with GCC 16 hardening

[Jan Polensky]

On Tue, May 26, 2026 at 09:59:41AM -0700, Ian Rogers wrote:
> On Tue, May 26, 2026 at 9:20 AM Jan Polensky <japo@linux.ibm.com> wrote:
> >
> > On Tue, May 26, 2026 at 08:23:28AM -0700, Ian Rogers wrote:
> > > On Tue, May 26, 2026 at 3:35 AM Jan Polensky <japo@linux.ibm.com> wrote:
> > > >
> > > > On Sat, May 23, 2026 at 11:49:22PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > > On Wed, May 20, 2026 at 01:09:05PM +0000, sashiko-bot@kernel.org wrote:
> > > > > > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
[snip]
>
> So it appears that part of the problem is declaring arrays and structs
> to be const. Making things non-const I think is also not an option.
> Would  EXTRA_CFLAGS="-fvisibility=hidden" help?
>
> It would we interesting to build with -Wl,-z,notext and then look for
> the symbol the linker is fighting with:
>   eu-findtextrel perf.cpython....so
> or
>   readelf -d perf.so | grep TEXTREL
>   readelf -r perf.so
>
> Thanks,
> Ian
>

Hi,

building the Python perf extension on s390x shows GCC version-dependent behavior.

Build command:
make NO_LIBTRACEEVENT=1 python-perf

Verified build results:

GCC 15.2.0 (Ubuntu 15.2.0-4ubuntu4)
GNU ld (GNU Binutils for Ubuntu) 2.45
Build succeeds and creates python/perf.cpython-313-s390x-linux-gnu.so
Verification:
readelf -d python/perf.cpython-313-s390x-linux-gnu.so | grep TEXTREL
Output:
0x0000000000000016 (TEXTREL)            0x0

GCC 16.1.0 (cross-compiler)
GNU ld (GNU Binutils) 2.46
Build succeeds and creates python/perf.cpython-313-s390x-linux-gnu.so
Verification:
readelf -d python/perf.cpython-313-s390x-linux-gnu.so | grep TEXTREL
No output

GCC 16.1.1 20260515 (Red Hat 16.1.1-2)
GNU ld version 2.46-3.fc44
Build fails with:
 /usr/bin/ld.bfd: error: read-only segment has dynamic relocations

Analysis:

Base libraries libapi, libperf, libsubcmd, and libsymbol compiled with -g/-ggdb3 create DWARF debug sections with absolute relocations (R_390_64). When statically linked into the Python shared library, these become TEXTREL entries.

Observed behavior:

GCC 15.2.0 generates TEXTREL.
GCC 16.1.0 does not generate TEXTREL.
GCC 16.1.1 generates TEXTREL.

Binutils 2.45 accepts shared libraries with TEXTREL.
Binutils 2.46 rejects them.

Question to clarify:

What changed between GCC 16.1.0 and 16.1.1 on s390x that reintroduced TEXTREL generation here?

Best regards,
Jan

Re: [PATCH 1/1] perf build: Fix Python extension build with GCC 16 hardening

[Namhyung Kim]

On Tue, May 26, 2026 at 09:59:41AM -0700, Ian Rogers wrote:
> On Tue, May 26, 2026 at 9:20 AM Jan Polensky <japo@linux.ibm.com> wrote:
> >
> > On Tue, May 26, 2026 at 08:23:28AM -0700, Ian Rogers wrote:
> > > On Tue, May 26, 2026 at 3:35 AM Jan Polensky <japo@linux.ibm.com> wrote:
> > > >
> > > > On Sat, May 23, 2026 at 11:49:22PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > > On Wed, May 20, 2026 at 01:09:05PM +0000, sashiko-bot@kernel.org wrote:
> > > > > > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > > > > > - [Medium] The patch explicitly allows text relocations in the Python extension shared object (`perf.so`) by adding `-Wl,-z,notext`, masking the root cause of missing `-fPIC` flags and breaking W^X (Write XOR Execute) security protections.
> > > > > > --
> > > > > >
> > > > > > commit f3832fb0ad0d1f9c2e69039b2a5110f77d220d5e
> > > > > > Author: Jan Polensky <japo@linux.ibm.com>
> > > > > >
> > > > > > perf build: Fix Python extension build with GCC 16 hardening
> > > > > >
> > > > > > This commit addresses a build failure in the Python extension caused by GCC 16
> > > > > > stricter security policies regarding dynamic relocations in read-only segments.
> > > > > > It adds the -Wl,-z,notext flag to the linker to explicitly allow text
> > > > > > relocations in the Python extension shared object.
> > > > > >
> > > > > > > diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> > > > > > > index 76b35ac19acbf..eea170d6576db 100644
> > > > > > > --- a/tools/perf/Makefile.perf
> > > > > > > +++ b/tools/perf/Makefile.perf
> > > > > > > @@ -749,7 +749,7 @@ all: shell_compatibility_test $(ALL_PROGRAMS) $(LANG_BINDINGS) $(OTHER_PROGRAMS)
> > > > > > >  $(shell [ -d '$(OUTPUT)python' ] || mkdir -p '$(OUTPUT)python')
> > > > > > >
> > > > > > >  $(OUTPUT)python/perf$(PYTHON_EXTENSION_SUFFIX): util/python.c util/setup.py $(PERFLIBS_PY)
> > > > > > > - $(QUIET_GEN)LDSHARED="$(CC) -pthread -shared" \
> > > > > > > + $(QUIET_GEN)LDSHARED="$(CC) -pthread -shared -Wl,-z,notext" \
> > > > > >
> > > > > > [Severity: Medium]
> > > > > > Does adding -Wl,-z,notext mask the root cause of the GCC 16 linker error?
> > > > > >
> > > > > > The error regarding dynamic relocations in a read-only segment usually
> > > > > > indicates that non-position-independent code from the static libraries
> > > > > > is being linked into the shared library.
> > > > > >
> > > > > > Using -Wl,-z,notext suppresses this error by allowing text relocations, which
> > > > > > forces the dynamic linker to map the executable text segment as writable at
> > > > > > load time. This breaks W^X security protections and weakens the security of
> > > > > > any Python process loading the extension.
> > > > > >
> > > > > > Should the required object files be compiled with -fPIC instead to properly
> > > > > > resolve the linker error without compromising security?
> > > > >
> > > > > So I asked Claude about this and he suggests doing like other parts of
> > > > > perf and using -fPIC, can you try to do that?
> > > > >
> > > > > ---------------------------------------
> > > > >
> > > > > ● Sashiko is right. -Wl,-z,notext is a band-aid that weakens security —
> > > > >   it makes the text segment writable at load time, defeating W^X.
> > > > >
> > > > >   The root cause is that PERFLIBS_PY (the static libraries linked into
> > > > >   the Python .so) are compiled without -fPIC. When you link non-PIC .a
> > > > >   archives into a shared library, the linker needs text relocations. GCC
> > > > >   16 correctly rejects this by default.
> > > > >
> > > > >   The proper fix is to build the static libraries that go into the
> > > > >   Python extension with -fPIC. The perf build system already has
> > > > >   precedent for this — look for how libperf and libsubcmd handle PIC
> > > > >   builds. The Python extension's dependencies need a parallel -fPIC
> > > > >   build, or the existing objects need to be compiled with -fPIC when the
> > > > >   Python binding is enabled.
> > > > >
> > > > >   The -Wl,-z,notext approach would also cause issues on distros that
> > > > >   enforce RELRO + BIND_NOW hardening, and some package builders would
> > > > >   reject the resulting .so outright.
> > > > >
> > > > > - Arnaldo
> > > >
> > > > Hi Arnaldo,
> > > >
> > > > thanks for the pointer. I double-checked this on s390x and did some reduced-link
> > > > testing for the ET_DYN / Python-extension case.
> > > >
> > > > The failure is not triggered by the perf Python binding object alone.
> > > >
> > > > A reduced reproducer succeeds when linking:
> > > >   python.o
> > > >   + libapi.a
> > > >   + libperf.a
> > > >   + libsubcmd.a
> > > >   + libsymbol.a
> > > >   + libbpf.a
> > > >   + libperf-ui.a
> > > >
> > > > The link starts to fail with:
> > > >   /usr/bin/ld.bfd: error: read-only segment has dynamic relocations
> > > >
> > > > as soon as libperf-util.a is added.
> > > >
> > > > In my tree, libperf-util.a currently contains only perf-util-in.o, and replacing
> > > > the archive with that single object still reproduces the same failure.
> > > >
> > > > Reduced reproducer:
> > > >
> > > >   gcc -pthread -shared \
> > > >     -Wl,-z,noexecstack \
> > > >     -o /tmp/try-perf-util-only.so \
> > > >     /root/linux/tools/perf/python_ext_build/tmp/root/linux/tools/perf/util/python.o \
> > > >     -Wl,--whole-archive \
> > > >       /root/linux/tools/perf/libapi/libapi.a \
> > > >       /root/linux/tools/perf/libperf/libperf.a \
> > > >       /root/linux/tools/perf/libsubcmd/libsubcmd.a \
> > > >       /root/linux/tools/perf/libsymbol/libsymbol.a \
> > > >       /root/linux/tools/perf/libbpf/libbpf.a \
> > > >       /root/linux/tools/perf/libperf-ui.a \
> > > >     -Wl,--no-whole-archive \
> > > >     /root/perf-util-one/perf-util-in.o \
> > > >     -lpython3.14 -lpthread -ldl -lm -lutil
> > > >
> > > > Inspection of perf-util-in.o on s390x shows many direct R_390_PC32DBL
> > > > relocations from .text against .data.rel.ro, .data.rel.ro.local,
> > > > .data.rel.local, .bss, and .rodata.
> > > >
> > > > Representative examples include:
> > > >
> > > >   arm64__associate_instruction_ops:
> > > >     larl %r6  -> R_390_PC32DBL .data.rel.ro+0x2
> > > >
> > > >   loongarch__associate_ins_ops:
> > > >     larl %r9  -> R_390_PC32DBL .data.rel.ro+0x22
> > > >     larl %r9  -> R_390_PC32DBL .data.rel.ro+0x42
> > > >
> > > >   check_ppc_insn:
> > > >     larl %r4  -> R_390_PC32DBL .data.rel.local+0x4c2
> > > >     larl %r2  -> R_390_PC32DBL .data.rel.ro.local+0x22
> > > >     larl %r1  -> R_390_PC32DBL .data.rel.local+0x2
> > > >     larl %r2  -> R_390_PC32DBL .data.rel.ro.local+0x2
> > > >
> > > >   s390__associate_ins_ops:
> > > >     larl %r10 -> R_390_PC32DBL .data.rel.ro+0x732
> > > >     larl %r10 -> R_390_PC32DBL .data.rel.ro+0x752
> > > >
> > > > So from my reproducer, I don't think we can describe this simply as
> > > > "all Python-extension dependency archives are missing -fPIC".
> > > >
> > > > The issue narrows down much more specifically to perf-util-in.o in the ET_DYN
> > > > link of the Python extension, and the direct text-to-data section relocations
> > > > above look like the most relevant candidates.
> > > >
> > > > So I agree that -Wl,-z,notext is only a workaround. I'd prefer to understand
> > > > and fix the underlying relocation pattern in perf-util-in.o rather than merge
> > > > that as-is.
> > > >
> > > > If useful, I can send the relevant readelf/objdump snippets in a follow-up.
> > >
> > > Hi Jan,
> > >
> > > I wonder about two tests:
> > > 1) adding V=1 JOBS=1 to your make command to switch on single
> > > threading and build verbosity. This may make it possible to identify
> > > the gcc command that is missing -fPIC. For example, I see -fPIC on
> > > x86:
> > >   gcc -Wp,-MD,/tmp/perf4/util/annotate-arch/.annotate-arm64.o.d
> > > -Wp,-MT,/tmp/perf4/util/annotate-arch/annotate -arm64.o
> > > -Wbad-function-cast -Wdeclaration-after-statement -Wformat-security
> > > -Wformat-y2k -Winit-self -Wmissin g-declarations -Wmissing-prototypes
> > > -Wno-system-headers -Wold-style-definition -Wpacked -Wredundant-decls
> > > -Wst rict-prototypes -Wswitch-default -Wswitch-enum -Wundef
> > > -Wwrite-strings -Wformat -Wno-type-limits -Wstrict-alia sing=3
> > > -Wshadow -fno-strict-aliasing -I/tmp/perf4/arch/x86/include/generated
> > > -DHAVE_ARCH_X86_64_SUPPORT -Werro r -g -fno-omit-frame-pointer -Wall
> > > -Wextra -std=gnu11 -funsigned-char -fstack-protector-all
> > > -D_LARGEFILE64_SOU RCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
> > > -I~/linux/tools/perf/util/include
> > > -I~/linux/tools/perf/arch/x86/include
> > > -I/usr/local/google/home/irogers/re pos/linux4/tools/include/
> > > -I~/linux/tools/arch/x86/include/uapi -I/usr/loc
> > > al/google/home/irogers/repos/linux4/tools/include/uapi
> > > -I~/linux/tools/arc h/x86/include/ -I~/linux/tools/arch/x86/
> > > -I/tmp/perf4//util -I/tmp/perf4/ -I~/linux/tools/perf/util
> > > -I~/linux/to ols/perf -DHAVE_PTHREAD_ATTR_SETAFFINITY_NP
> > > -DHAVE_PTHREAD_BARRIER -DHAVE_EVENTFD_SUPPORT -DHAVE_GETTID -DHAVE
> > > _FILE_HANDLE -DHAVE_AIO_SUPPORT -DHAVE_SCANDIRAT_SUPPORT
> > > -DHAVE_SCHED_GETCPU_SUPPORT -DHAVE_SETNS_SUPPORT -DHA VE_ZLIB_SUPPORT
> > > -DHAVE_LIBELF_SUPPORT -DHAVE_ELF_GETPHDRNUM_SUPPORT
> > > -DHAVE_GELF_GETNOTE_SUPPORT -DHAVE_ELF_GET SHDRSTRNDX_SUPPORT
> > > -DHAVE_DEBUGINFOD_SUPPORT -DHAVE_LIBDW_SUPPORT -DHAVE_LIBBPF_SUPPORT
> > > -DHAVE_SDT_EVENT -DHAV E_JITDUMP -DHAVE_LIBOPENSSL_SUPPORT
> > > -DHAVE_BPF_SKEL -DHAVE_DWARF_UNWIND_SUPPORT -DHAVE_SLANG_SUPPORT
> > > -DHAVE_TI MERFD_SUPPORT -fPIC -DHAVE_LIBLLVM_SUPPORT
> > > -I/usr/lib/llvm-19/include -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
> > > -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> > > -DHAVE_CXA_DEMANGLE_SUPPORT -DHAVE_LZMA_SUPPORT -DHAVE_ZSTD_SUPPORT
> > > -DHAVE_BACKTRACE_SUPPORT -DHAVE_LIBNUMA_SUPPORT
> > > -DHAVE_PERF_READ_VDSO32 -DHAVE_LIBBABELTRACE_SUPPORT -DHAVE_
> > > LIBCAPSTONE_SUPPORT -DHAVE_JVMTI_CMLR -DHAVE_LIBPFM
> > > -DHAVE_LIBTRACEEVENT -I/usr/include/traceevent -DLIBTRACEE
> > > VENT_VERSION=67072 -DHAVE_RUST_SUPPORT -I/tmp/perf4/libapi/include
> > > -I/tmp/perf4/libbpf/include -I/tmp/perf4/li bsubcmd/include
> > > -I/tmp/perf4/libsymbol/include -I/tmp/perf4/libperf/include
> > > -I/tmp/perf4/ -D"BUILD_STR(s)=#s" -c -o
> > > /tmp/perf4/util/annotate-arch/annotate-arm64.o
> > > util/annotate-arch/annotate-arm64.c
> > >
> > > 2) adding EXTRA_CFLAGS="-fPIC" to your make command. This should force
> > > this option wherever it might be missing.
> > >
> > > Thanks,
> > > Ian
> > >
> > > > Best regards,
> > > > Jan
> > > >
> > Hi Ian,
> >
> > I tested both suggestions the second in the beginning of my research:
> >
> > EXTRA_CFLAGS="-fPIC" - Does NOT work. Same error:
> >
> > /usr/bin/ld.bfd: error: read-only segment has dynamic relocations
> > collect2: error: ld returned 1 exit status
> >
> > The issue is s390x-specific R_390_PC32DBL relocations in perf-util-in.o
> > (from `larl` instructions) that persist even with -fPIC.
> >
> > Current options:
> > 1. Use -Wl,-z,notext (security issue)
> > 2. Refactor code to avoid these relocations
> > 3. Disable Python extension on s390x (not an option)
> >
> > Thoughts?
> 
> So it appears that part of the problem is declaring arrays and structs
> to be const. Making things non-const I think is also not an option.
> Would  EXTRA_CFLAGS="-fvisibility=hidden" help?
> 
> It would we interesting to build with -Wl,-z,notext and then look for
> the symbol the linker is fighting with:
>   eu-findtextrel perf.cpython....so
> or
>   readelf -d perf.so | grep TEXTREL
>   readelf -r perf.so

I'm curious if it's s390 specific.  I don't know what code patterns make
it relocatable.  Is taking an address of struct ins_ops variable a
problem?  Does it matter being a static variable?

Thanks,
Namhyung