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

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

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