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

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

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