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

[Leo Yan <leo.yan@arm.com>]

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/