* Re: [PATCH] arm64: perf: fix syscalltbl path base [not found] <b2651f20-6f3a-49f5-9cd8-3fb028b2cab5@app.fastmail.com> @ 2025-12-15 8:47 ` James Clark 2025-12-15 9:33 ` Arnd Bergmann 0 siblings, 1 reply; 8+ messages in thread From: James Clark @ 2025-12-15 8:47 UTC (permalink / raw) To: Joel May, catalin.marinas, will, Leo Yan Cc: linux-arm-kernel, arnd, Linux perf Profiling 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] arm64: perf: fix syscalltbl path base 2025-12-15 8:47 ` [PATCH] arm64: perf: fix syscalltbl path base James Clark @ 2025-12-15 9:33 ` Arnd Bergmann 2025-12-15 10:52 ` James Clark 0 siblings, 1 reply; 8+ messages in thread From: Arnd Bergmann @ 2025-12-15 9:33 UTC (permalink / raw) To: James Clark, Joel May, Catalin Marinas, Will Deacon, Leo Yan Cc: linux-arm-kernel, Linux perf Profiling 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] arm64: perf: fix syscalltbl path base 2025-12-15 9:33 ` Arnd Bergmann @ 2025-12-15 10:52 ` James Clark 2025-12-15 11:28 ` Leo Yan 0 siblings, 1 reply; 8+ messages in thread From: James Clark @ 2025-12-15 10:52 UTC (permalink / raw) To: Arnd Bergmann, Joel May, Leo Yan, Ian Rogers Cc: linux-arm-kernel, Linux perf Profiling, Catalin Marinas, Will Deacon 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] arm64: perf: fix syscalltbl path base 2025-12-15 10:52 ` James Clark @ 2025-12-15 11:28 ` Leo Yan 2025-12-15 12:22 ` Arnd Bergmann 0 siblings, 1 reply; 8+ messages in thread From: Leo Yan @ 2025-12-15 11:28 UTC (permalink / raw) To: James Clark Cc: Arnd Bergmann, Joel May, Ian Rogers, linux-arm-kernel, Linux perf Profiling, Catalin Marinas, Will Deacon 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] arm64: perf: fix syscalltbl path base 2025-12-15 11:28 ` Leo Yan @ 2025-12-15 12:22 ` Arnd Bergmann 2025-12-15 16:49 ` Leo Yan 0 siblings, 1 reply; 8+ messages in thread From: Arnd Bergmann @ 2025-12-15 12:22 UTC (permalink / raw) To: Leo Yan, James Clark Cc: Joel May, Ian Rogers, linux-arm-kernel, Linux perf Profiling, Catalin Marinas, Will Deacon 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] arm64: perf: fix syscalltbl path base 2025-12-15 12:22 ` Arnd Bergmann @ 2025-12-15 16:49 ` Leo Yan 2025-12-16 7:17 ` Arnd Bergmann 0 siblings, 1 reply; 8+ messages in thread From: Leo Yan @ 2025-12-15 16:49 UTC (permalink / raw) To: Arnd Bergmann Cc: James Clark, Joel May, Ian Rogers, linux-arm-kernel, Linux perf Profiling, Catalin Marinas, Will Deacon 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/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] arm64: perf: fix syscalltbl path base 2025-12-15 16:49 ` Leo Yan @ 2025-12-16 7:17 ` Arnd Bergmann 2025-12-16 12:04 ` Leo Yan 0 siblings, 1 reply; 8+ messages in thread From: Arnd Bergmann @ 2025-12-16 7:17 UTC (permalink / raw) To: Leo Yan Cc: James Clark, Joel May, Ian Rogers, linux-arm-kernel, Linux perf Profiling, Catalin Marinas, Will Deacon 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] arm64: perf: fix syscalltbl path base 2025-12-16 7:17 ` Arnd Bergmann @ 2025-12-16 12:04 ` Leo Yan 0 siblings, 0 replies; 8+ messages in thread From: Leo Yan @ 2025-12-16 12:04 UTC (permalink / raw) To: Arnd Bergmann Cc: James Clark, Joel May, Ian Rogers, linux-arm-kernel, Linux perf Profiling, Catalin Marinas, Will Deacon, Arnaldo Carvalho de Melo, Namhyung Kim 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2025-12-16 12:04 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <b2651f20-6f3a-49f5-9cd8-3fb028b2cab5@app.fastmail.com>
2025-12-15 8:47 ` [PATCH] arm64: perf: fix syscalltbl path base James Clark
2025-12-15 9:33 ` Arnd Bergmann
2025-12-15 10:52 ` James Clark
2025-12-15 11:28 ` Leo Yan
2025-12-15 12:22 ` Arnd Bergmann
2025-12-15 16:49 ` Leo Yan
2025-12-16 7:17 ` Arnd Bergmann
2025-12-16 12:04 ` Leo Yan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).