Re: [PATCH] arm64: perf: fix syscalltbl path base

Re: [PATCH] arm64: perf: fix syscalltbl path base

[James Clark]

On 15/12/2025 00:12, Joel May wrote:
> From: Joel May <joel-linux@jmay.us>
> 
> A fix for the Perf build process was introduced in commit bfb713ea53c74
> ("perf tools: Fix arm64 build by generating unistd_64.h"), which generates
> the unistd_64.h header as necessary.  This fix works fine in some
> scenarios.
> 
> My problem is when building Perf from tools/perf with SRCARCH=arm64, the
> path used in scripts/Makefile.asm-headers is relative to tools/perf
> instead of root directory.  This results in the build failing like so.
> This snippet is a simplified repro of the problem, see the link to the
> TrueNAS SCALE build script to see the problem in context.
> 
>    jmay@debian13-aarch64:/mnt/linux/linux-vanilla/tools/perf$ ARCH=arm64 SRCARCH=arm64 make -j1
>    ...
>    make[4]: *** No rule to make target '/mnt/linux/linux-vanilla/tools/perf/libperf/arch/arm64/include/generated/uapi/asm/unistd_64.h'.  Stop.
>    make[3]: *** [Makefile:108: uapi-asm-generic] Error 2
>    make[2]: *** [Makefile.perf:972: /mnt/linux/linux-vanilla/tools/perf/libperf/libperf.a] Error 2
> 
> The problem is that scripts/Makefile.asm-headers is including a relative
> syscalltbl path from arch/arm64/kernel/Makefile.syscalls.  The syscalltbl
> path needs to be based on the srctree root.
> 
> Fixes: 7fe33e9f662c0 ("arm64: convert unistd_32.h to syscall.tbl format")
> Fixes: bfb713ea53c74 ("perf tools: Fix arm64 build by generating unistd_64.h")

Hi Joel,

There is a similar fix on the list here:

https://lore.kernel.org/linux-perf-users/20251204-perf_fix_syscall_header-v1-1-b8e27f74ed6a@arm.com/

I'm not sure if commit 1 alone will also fix your issue, or we'd need to 
collapse both of the commits in that set.

The first commit has an older fixes: tag and also fixes some other 
issues so it might be better to take that one rather than this one.

Thanks
James

> Link: https://github.com/truenas/linux/commit/91377b555a57dfa75364d7da85b5e21e41e81625#diff-831a0e8e3eaa7a5ca92599e58771b8a6b2c4bd7533f627e33138873995aac61eR147
> Signed-off-by: Joel May <joel-linux@jmay.us>
> ---
>   arch/arm64/kernel/Makefile.syscalls | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kernel/Makefile.syscalls b/arch/arm64/kernel/Makefile.syscalls
> index 0542a718871a..958f2335ec1b 100644
> --- a/arch/arm64/kernel/Makefile.syscalls
> +++ b/arch/arm64/kernel/Makefile.syscalls
> @@ -3,4 +3,4 @@
>   syscall_abis_32 +=
>   syscall_abis_64 += renameat rlimit memfd_secret
>   
> -syscalltbl = arch/arm64/tools/syscall_%.tbl
> +syscalltbl = $(srctree)/arch/arm64/tools/syscall_%.tbl
> 
> base-commit: edde060637b92607f3522252c03d64ad06369933

Re: [PATCH] arm64: perf: fix syscalltbl path base

[Arnd Bergmann]

On Mon, Dec 15, 2025, at 09:47, James Clark wrote:
> On 15/12/2025 00:12, Joel May wrote:
>
> Hi Joel,
>
> There is a similar fix on the list here:
>
> https://lore.kernel.org/linux-perf-users/20251204-perf_fix_syscall_header-v1-1-b8e27f74ed6a@arm.com/
>
> I'm not sure if commit 1 alone will also fix your issue, or we'd need to 
> collapse both of the commits in that set.
>
> The first commit has an older fixes: tag and also fixes some other 
> issues so it might be better to take that one rather than this one.

I don't understand that other "fix", doesn't that just work around
the arm64 build issue by adding another special case for arm64?

If we want the tools directory to have a copy of the generated unistd.h
files instead of generating them, it should at the minimum be done
the same across all architectures.

    Arnd

Re: [PATCH] arm64: perf: fix syscalltbl path base

[James Clark]

On 15/12/2025 11:33, Arnd Bergmann wrote:
> On Mon, Dec 15, 2025, at 09:47, James Clark wrote:
>> On 15/12/2025 00:12, Joel May wrote:
>>
>> Hi Joel,
>>
>> There is a similar fix on the list here:
>>
>> https://lore.kernel.org/linux-perf-users/20251204-perf_fix_syscall_header-v1-1-b8e27f74ed6a@arm.com/
>>
>> I'm not sure if commit 1 alone will also fix your issue, or we'd need to
>> collapse both of the commits in that set.
>>
>> The first commit has an older fixes: tag and also fixes some other
>> issues so it might be better to take that one rather than this one.
> 
> I don't understand that other "fix", doesn't that just work around
> the arm64 build issue by adding another special case for arm64?
> 
> If we want the tools directory to have a copy of the generated unistd.h
> files instead of generating them, it should at the minimum be done
> the same across all architectures.
> 
>      Arnd

I don't think it's a special case, the other architectures already have 
a copy of their syscall headers in tools/ don't they?

My original commit that is reverted by Leo's patches is more of a "fix" 
than his fix. It turned out that running the generator script for the 
Perf build wasn't the best idea after all. Now it's obvious that we'd 
have to keep injecting that build rule into every tool that needs it. 
And it doesn't even respect this rule described here that tools headers 
should be decoupled from the kernel sources:

  linux/tools/include/uapi/README

I don't see the benefit of manually copying over the generator script 
and its input file and then updating every build rule to invoke it when 
we can manually copy over the output of that script and not have to do 
anything else.

Ian makes the point that we can run the generator for doing 
check_headers.sh. But at least that only needs to be done for one tool 
and can be in addition to the manual copy.

James

Re: [PATCH] arm64: perf: fix syscalltbl path base

[Leo Yan]

On Mon, Dec 15, 2025 at 12:52:24PM +0200, James Clark wrote:

[...]

> On 15/12/2025 11:33, Arnd Bergmann wrote:
> > On Mon, Dec 15, 2025, at 09:47, James Clark wrote:
> > > On 15/12/2025 00:12, Joel May wrote:
> > > 
> > > Hi Joel,
> > > 
> > > There is a similar fix on the list here:
> > > 
> > > https://lore.kernel.org/linux-perf-users/20251204-perf_fix_syscall_header-v1-1-b8e27f74ed6a@arm.com/
> > > 
> > > I'm not sure if commit 1 alone will also fix your issue, or we'd need to
> > > collapse both of the commits in that set.

We need to apply both patches in the share link - we need to apply the
second patch to revert generating unistd_64.h in libperf.

> > > The first commit has an older fixes: tag and also fixes some other
> > > issues so it might be better to take that one rather than this one.
> > 
> > I don't understand that other "fix", doesn't that just work around
> > the arm64 build issue by adding another special case for arm64?
> > 
> > If we want the tools directory to have a copy of the generated unistd.h
> > files instead of generating them, it should at the minimum be done
> > the same across all architectures.
> 
> I don't think it's a special case, the other architectures already have a
> copy of their syscall headers in tools/ don't they?

Correct.  Most of architectures simply include

    tools/include/uapi/asm-generic/unistd.h

x86 includes their own unistd_32/64.h; only arm64 attempted to generate
unistd_64.h dynamically, but this is problem for build dependency - when
build perf, feature tests in tools/build/feature/ run before libperf and
fail if unistd_64.h has not yet been generated by libperf Makefile.

> My original commit that is reverted by Leo's patches is more of a "fix" than
> his fix. It turned out that running the generator script for the Perf build
> wasn't the best idea after all. Now it's obvious that we'd have to keep
> injecting that build rule into every tool that needs it. And it doesn't even
> respect this rule described here that tools headers should be decoupled from
> the kernel sources:
> 
>  linux/tools/include/uapi/README
> 
> I don't see the benefit of manually copying over the generator script and
> its input file and then updating every build rule to invoke it when we can
> manually copy over the output of that script and not have to do anything
> else.
> 
> Ian makes the point that we can run the generator for doing
> check_headers.sh. But at least that only needs to be done for one tool and
> can be in addition to the manual copy.
> 
> James

Re: [PATCH] arm64: perf: fix syscalltbl path base

[Arnd Bergmann]

On Mon, Dec 15, 2025, at 12:28, Leo Yan wrote:
> On Mon, Dec 15, 2025 at 12:52:24PM +0200, James Clark wrote:
>> On 15/12/2025 11:33, Arnd Bergmann wrote:
>> > On Mon, Dec 15, 2025, at 09:47, James Clark wrote:
>> > > The first commit has an older fixes: tag and also fixes some other
>> > > issues so it might be better to take that one rather than this one.
>> > 
>> > I don't understand that other "fix", doesn't that just work around
>> > the arm64 build issue by adding another special case for arm64?
>> > 
>> > If we want the tools directory to have a copy of the generated unistd.h
>> > files instead of generating them, it should at the minimum be done
>> > the same across all architectures.
>> 
>> I don't think it's a special case, the other architectures already have a
>> copy of their syscall headers in tools/ don't they?
>
> Correct.  Most of architectures simply include
>
>     tools/include/uapi/asm-generic/unistd.h
>
> x86 includes their own unistd_32/64.h; only arm64 attempted to generate
> unistd_64.h dynamically, but this is problem for build dependency - when
> build perf, feature tests in tools/build/feature/ run before libperf and
> fail if unistd_64.h has not yet been generated by libperf Makefile.

Ah, I see now that arc/hexagon/loongarch/riscv just use an old
copy of the header based on the and no longer update them. I only
saw that they have the stub version but hadn't realized that they
never updated past the point where we started generating the
ones for the uapi.

Still, I would suggest using the same method across all architectures:
either we figure out how to use the generated headers on all of them
(including x86, which uses yet another method), or we just stick with
the old asm-generic/unistd.h copy and use that on arm64 as well.

     Arnd

Re: [PATCH] arm64: perf: fix syscalltbl path base

[Leo Yan]

On Mon, Dec 15, 2025 at 01:22:04PM +0100, Arnd Bergmann wrote:

[...]

> Ah, I see now that arc/hexagon/loongarch/riscv just use an old
> copy of the header based on the and no longer update them. I only
> saw that they have the stub version but hadn't realized that they
> never updated past the point where we started generating the
> ones for the uapi.
> 
> Still, I would suggest using the same method across all architectures:
> either we figure out how to use the generated headers on all of them
> (including x86, which uses yet another method)

Switching to generated unistd.h headers would require removing
tools/include/uapi/asm-generic/unistd.h and generating unistd_64/32.h
on the fly, while still keeping arch's stub headers under
tools/arch/${arch}/include/uapi/asm/.

As discussed in [1], I would prefer to drop these headers, but Ian
noted that this could break builds with older toolchains.  We keep the
tools/ copies of unistd.h because tools need the latest syscall
numbers; relying on outdated toolchain headers can lead to build
failures or incorrect behavior (e.g., perf falling back to predefined
but wrong syscall numbers).

One idea is to install kernel headers first and then build tools, e,g.:

   cd linux
   export CROSS_COMPILE=aarch64-linux-gnu-
   make ARCH=arm64 headers_install O=$OUT
   make ARCH=arm64 O=$OUT -C tools/perf

Generating the headers dynamically would avoid maintaining duplicated
copies under tools/ and no need for periodic syncs.  However, this is a
quite big effort, not just perf, we need to update makefiles to the path
of the installed headers.  I'd like to hear opinions from tools
(perf/bpf/selftest) maintainers before proceeding.

> or we just stick with
> the old asm-generic/unistd.h copy and use that on arm64 as well.

I will proceed this way for now.  From a maintenance view, it is a
pragmatic solution that only requires reverting a few patches and does
not introduce any new code.

Thanks for your suggestion!

Leo

[1] https://lore.kernel.org/linux-perf-users/20251209104926.GS724103@e132581.arm.com/

Re: [PATCH] arm64: perf: fix syscalltbl path base

[Arnd Bergmann]

On Mon, Dec 15, 2025, at 17:49, Leo Yan wrote:
> On Mon, Dec 15, 2025 at 01:22:04PM +0100, Arnd Bergmann wrote:
> As discussed in [1], I would prefer to drop these headers, but Ian
> noted that this could break builds with older toolchains.

I didn't find the reference to breaking, do you just mean it
would break when falling back to a header provided by the
toolchain's own asm/unistd.h, or a problem with the modern
generated version that is solved by using the old asm-generic
file?

> Generating the headers dynamically would avoid maintaining duplicated
> copies under tools/ and no need for periodic syncs.  However, this is a
> quite big effort, not just perf, we need to update makefiles to the path
> of the installed headers.  I'd like to hear opinions from tools
> (perf/bpf/selftest) maintainers before proceeding.

I see that we do ship the sources for generating headers on
most architectures in tools/perf/arch/*/entry/syscalls/syscall*.tbl,
the only exceptions being mips-o32, mips-n32 and x86.

I would also point out that s390 no longer needs a custom script
as of 6.19, since the last incompatibility between the s390 format
and the x86 format of the tbl files got resolved with the removal
of the s390 compat mode.

>> or we just stick with
>> the old asm-generic/unistd.h copy and use that on arm64 as well.
>
> I will proceed this way for now.  From a maintenance view, it is a
> pragmatic solution that only requires reverting a few patches and does
> not introduce any new code.

Note that if we ever need to update the
tools/include/uapi/asm-generic/unistd.h file for new syscalls,
that will get harder in the future once we remove the
kernel's own include/uapi/asm-generic/unistd.h. I'm sorry
I never sent that fix after the previous cleanup that introduced
the common script.

     Arnd

Re: [PATCH] arm64: perf: fix syscalltbl path base

[Leo Yan]

On Tue, Dec 16, 2025 at 08:17:51AM +0100, Arnd Bergmann wrote:

[...]

> I didn't find the reference to breaking, do you just mean it
> would break when falling back to a header provided by the
> toolchain's own asm/unistd.h, or a problem with the modern
> generated version that is solved by using the old asm-generic
> file?

Sorry for confusion.  I mean build breakage caused by using
toolchain's own asm/unistd.h.

> I would also point out that s390 no longer needs a custom script
> as of 6.19, since the last incompatibility between the s390 format
> and the x86 format of the tbl files got resolved with the removal
> of the s390 compat mode.

Thanks for the info.  I saw 4ac286c4a8d9 ("s390/syscalls: Switch to
generic system call table generation") for the s390 consolidation.

To be clear, Perf makefile now only uses
tools/perf/arch/*/entry/syscalls/syscall*.tbl to create syscall arrays
for tracing (e.g., print beauty string for syscall trace).

The dilemma is that the *.tbl files are in ./tools/perf, if we generate
unistd_64/32.h headers are not visible to other programs under ./tools.

> >> or we just stick with
> >> the old asm-generic/unistd.h copy and use that on arm64 as well.
> >
> > I will proceed this way for now.  From a maintenance view, it is a
> > pragmatic solution that only requires reverting a few patches and does
> > not introduce any new code.
> 
> Note that if we ever need to update the
> tools/include/uapi/asm-generic/unistd.h file for new syscalls,
> that will get harder in the future once we remove the
> kernel's own include/uapi/asm-generic/unistd.h. I'm sorry
> I never sent that fix after the previous cleanup that introduced
> the common script.

I agree this is a potential risk if we stick to static headers.

Thanks,
Leo