[PATCH v3 0/3] tools build: Fix arm64 unistd.h dependency

[PATCH v3 0/3] tools build: Fix arm64 unistd.h dependency

[Leo Yan]

The perf build includes arm64's unistd.h, but its dependent header
unistd_64.h is missing.

As suggested by Arnd in [1]:

  "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."

A dynamic approach (e.g., make headers_install) may be explored later to
generate headers for tools, but that will need consensus from the tools
maintainers.  In the meantime, this series provides a quick fix by using
the asm-generic/unistd.h copy for arm64.

[1] https://lore.kernel.org/linux-arm-kernel/20251222173653.GF9788@e132581.arm.com/T/#m69a051aae5e53a65f9b10e1d13f67b3e92f4bbc7

Signed-off-by: Leo Yan <leo.yan@arm.com>
---
Changes in v3:
- Changed to include asm-generic/unistd.h copy (Arnd).
- Removed check due to divergence between the kernel and tools.
- Link to v2: https://lore.kernel.org/r/20251210-perf_fix_syscall_header-v2-0-b18b6016e0ea@arm.com

Changes in v2:
- Added a consistency check (Ian).
- Rebased on the latest perf-tools-next.
- Link to v1: https://lore.kernel.org/r/20251204-perf_fix_syscall_header-v1-0-b8e27f74ed6a@arm.com

---
Leo Yan (3):
      tools headers: Go back to include asm-generic/unistd.h for arm64
      Revert "perf tools: Fix arm64 build by generating unistd_64.h"
      tools headers: Don't check arm64's unistd.h

 tools/arch/arm64/include/uapi/asm/unistd.h | 24 +++++++++++++++++++++++-
 tools/lib/perf/Makefile                    | 14 ++------------
 tools/perf/Makefile.config                 |  1 -
 tools/perf/check-headers.sh                |  1 -
 4 files changed, 25 insertions(+), 15 deletions(-)
---
base-commit: cb015814f8b6eebcbb8e46e111d108892c5e6821
change-id: 20251203-perf_fix_syscall_header-e280fa931d44

Best regards,
-- 
Leo Yan <leo.yan@arm.com>

[PATCH v3 1/3] tools headers: Go back to include asm-generic/unistd.h for arm64

[Leo Yan]

The header unistd.h is included under Arm64's uAPI folder (see
tools/arch/arm64/include/uapi/asm/), but it does not include its
dependent header unistd_64.h.  The intention is for unistd_64.h to be
generated dynamically using scripts/Makefile.asm-headers.

However, this dynamic approach causes problems because the header is not
available early enough, even though it is widely included throughout
tools.  Using the perf build as an example:

 1) Feature detection: Perf first runs feature tests.

    The BPF feature program test-bpf.c includes unistd.h.  Since
    unistd_64.h has not been generated yet, the program fails to build,
    and the BPF feature ends up being disabled.

 2) libperf build:

    The libperf Makefile later generates unistd_64.h on the fly, so
    libperf itself builds successfully.

 3) Final perf build:

    Although the perf binary can build successfully using the generated
    header, we never get a chance to build BPF skeleton programs,
    because BPF support was already disabled earlier.

To fix the issue, it restores to include asm-generic/unistd.h.  This is
consistent with other architectures and ensures the header is available
from the start.

Fixes: 22f72088ffe6 ("tools headers: Update the syscall table with the kernel sources")
Signed-off-by: Leo Yan <leo.yan@arm.com>
---
 tools/arch/arm64/include/uapi/asm/unistd.h | 24 +++++++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/tools/arch/arm64/include/uapi/asm/unistd.h b/tools/arch/arm64/include/uapi/asm/unistd.h
index df36f23876e863ff0a9e88473d5339f7ab69516d..9306726337fe005e3cf3e1ffd38dc6356191fa95 100644
--- a/tools/arch/arm64/include/uapi/asm/unistd.h
+++ b/tools/arch/arm64/include/uapi/asm/unistd.h
@@ -1,2 +1,24 @@
 /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#include <asm/unistd_64.h>
+/*
+ * Copyright (C) 2012 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#define __ARCH_WANT_RENAMEAT
+#define __ARCH_WANT_NEW_STAT
+#define __ARCH_WANT_SET_GET_RLIMIT
+#define __ARCH_WANT_TIME32_SYSCALLS
+#define __ARCH_WANT_MEMFD_SECRET
+
+#include <asm-generic/unistd.h>

-- 
2.34.1

Re: [PATCH v3 1/3] tools headers: Go back to include asm-generic/unistd.h for arm64

[James Clark]

On 22/12/2025 6:06 pm, Leo Yan wrote:
> The header unistd.h is included under Arm64's uAPI folder (see
> tools/arch/arm64/include/uapi/asm/), but it does not include its
> dependent header unistd_64.h.  The intention is for unistd_64.h to be
> generated dynamically using scripts/Makefile.asm-headers.
> 
> However, this dynamic approach causes problems because the header is not
> available early enough, even though it is widely included throughout
> tools.  Using the perf build as an example:
> 
>   1) Feature detection: Perf first runs feature tests.
> 
>      The BPF feature program test-bpf.c includes unistd.h.  Since
>      unistd_64.h has not been generated yet, the program fails to build,
>      and the BPF feature ends up being disabled.
> 
>   2) libperf build:
> 
>      The libperf Makefile later generates unistd_64.h on the fly, so
>      libperf itself builds successfully.
> 
>   3) Final perf build:
> 
>      Although the perf binary can build successfully using the generated
>      header, we never get a chance to build BPF skeleton programs,
>      because BPF support was already disabled earlier.
> 
> To fix the issue, it restores to include asm-generic/unistd.h.  This is

Would this prevent us from using any Arm64 specific syscalls in the 
future? I think that's a downside of this approach vs copying the 
generated output that should be noted here.

> consistent with other architectures and ensures the header is available

'Consistent' isn't accurate is it? x86 already has static copies of 
syscalls in tools/arch/x86/include/uapi/asm/unistd_32.h and 
tools/arch/x86/include/uapi/asm/unistd_64.h.

Maybe something more like "eventual consistency" is intended, if we plan 
to remove those x86 headers too? I'm still a bit lost about why Arm64 
copying the generated header is considered a special case when we 
already have these x86 ones.

> from the start.
> 
> Fixes: 22f72088ffe6 ("tools headers: Update the syscall table with the kernel sources")
> Signed-off-by: Leo Yan <leo.yan@arm.com>
> ---
>   tools/arch/arm64/include/uapi/asm/unistd.h | 24 +++++++++++++++++++++++-
>   1 file changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/arch/arm64/include/uapi/asm/unistd.h b/tools/arch/arm64/include/uapi/asm/unistd.h
> index df36f23876e863ff0a9e88473d5339f7ab69516d..9306726337fe005e3cf3e1ffd38dc6356191fa95 100644
> --- a/tools/arch/arm64/include/uapi/asm/unistd.h
> +++ b/tools/arch/arm64/include/uapi/asm/unistd.h
> @@ -1,2 +1,24 @@
>   /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> -#include <asm/unistd_64.h>
> +/*
> + * Copyright (C) 2012 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#define __ARCH_WANT_RENAMEAT
> +#define __ARCH_WANT_NEW_STAT
> +#define __ARCH_WANT_SET_GET_RLIMIT
> +#define __ARCH_WANT_TIME32_SYSCALLS
> +#define __ARCH_WANT_MEMFD_SECRET
> +
> +#include <asm-generic/unistd.h>
> 

Re: [PATCH v3 1/3] tools headers: Go back to include asm-generic/unistd.h for arm64

[Leo Yan]

On Wed, Dec 24, 2025 at 01:47:51PM +0000, James Clark wrote:

[...]

> > To fix the issue, it restores to include asm-generic/unistd.h.  This is
> 
> Would this prevent us from using any Arm64 specific syscalls in the future?

I hope the perf code can be general enough so don't call arch specific
syscalls.

> I think that's a downside of this approach vs copying the generated output
> that should be noted here.

From pragmatic view, I don't see any issue with using the
asm-generic/unistd.h on Arm64 at current stage.

If later we need to support new syscalls, I assume it is very likely not
an issue for Arm64 specific, we need to resolve common issue either
updating asm-generic/unistd.h or change to use dynamic generated headers.

> > consistent with other architectures and ensures the header is available
> 
> 'Consistent' isn't accurate is it? x86 already has static copies of syscalls
> in tools/arch/x86/include/uapi/asm/unistd_32.h and
> tools/arch/x86/include/uapi/asm/unistd_64.h.

I went through a bit x86's unistd_32.h/unistd_64.h, it defines some
special syscall numbers.  Seems removing them will break on x86.
I'd leave this to x86 maintainers.

To avoid confusion, I will update the commit log:

  Restore to include asm-generic/unistd.h for fixing the issue.  This
  aligns with most architectures (x86 is a special case that keeps
  unistd_32.h/unistd_64.h for its particular syscall numbers) and
  ensures the header is available from the start.

> Maybe something more like "eventual consistency" is intended, if we plan to
> remove those x86 headers too?

Yes.

> I'm still a bit lost about why Arm64 copying
> the generated header is considered a special case when we already have these
> x86 ones.

If arm64 maintains its own unistd.h, there is a concern that other
architectures will do the same, and we will end up maintaining
fragmented headers for each architecture.

Later, if we need to support architecture specific syscalls, we should
explore better approaches, such as using generated headers (e.g.,
make headers) to provide UAPI headers instead.

IMO, in this case, x86 is not a good example to follow.

Thanks,
Leo

Re: [PATCH v3 1/3] tools headers: Go back to include asm-generic/unistd.h for arm64

[Arnd Bergmann]

On Wed, Jan 7, 2026, at 15:48, Leo Yan wrote:
> On Wed, Dec 24, 2025 at 01:47:51PM +0000, James Clark wrote:
>> > To fix the issue, it restores to include asm-generic/unistd.h.  This is
>> 
>> Would this prevent us from using any Arm64 specific syscalls in the future?
>
> I hope the perf code can be general enough so don't call arch specific
> syscalls.
>
>> I think that's a downside of this approach vs copying the generated output
>> that should be noted here.
>
> From pragmatic view, I don't see any issue with using the
> asm-generic/unistd.h on Arm64 at current stage.
>
> If later we need to support new syscalls, I assume it is very likely not
> an issue for Arm64 specific, we need to resolve common issue either
> updating asm-generic/unistd.h or change to use dynamic generated headers.

Right, the arm64 table is currently shared with arc/hexagon/loongarch/riscv.

There won't be any new arm64 specific syscalls, but the kernel's
own uapi/asm-generic/unistd.h file is going away, so the
tools/include/uapi/asm-generic/unistd.h copy will become harder
to keep in sync with scripts/syscall.tbl in the future.

>> I'm still a bit lost about why Arm64 copying
>> the generated header is considered a special case when we already have these
>> x86 ones.
>
> If arm64 maintains its own unistd.h, there is a concern that other
> architectures will do the same, and we will end up maintaining
> fragmented headers for each architecture.
>
> Later, if we need to support architecture specific syscalls, we should
> explore better approaches, such as using generated headers (e.g.,
> make headers) to provide UAPI headers instead.

I think the more important issue with the current code is that
we don't support the older architectures besides x86: arm32, powerpc,
s390, mips, etc all have a custom syscall.tbl file like x86 but
don't have any asm/unistd.h installed in tools. If we want to
support any of them in the future, we should start generating the
files the same way we do for the kernel. There is already a copy
of the syscall.tbl files in tools/perf/arch/*/entry/syscalls/syscall*.tbl
and the arch/mips/kernel/syscalls/Makefile
just not the corresponding scripts/syscallhdr.sh.

     Arnd

Re: [PATCH v3 1/3] tools headers: Go back to include asm-generic/unistd.h for arm64

[Leo Yan]

On Wed, Jan 07, 2026 at 04:21:28PM +0100, Arnd Bergmann wrote:

[...]

> >> I'm still a bit lost about why Arm64 copying
> >> the generated header is considered a special case when we already have these
> >> x86 ones.
> >
> > If arm64 maintains its own unistd.h, there is a concern that other
> > architectures will do the same, and we will end up maintaining
> > fragmented headers for each architecture.
> >
> > Later, if we need to support architecture specific syscalls, we should
> > explore better approaches, such as using generated headers (e.g.,
> > make headers) to provide UAPI headers instead.
> 
> I think the more important issue with the current code is that
> we don't support the older architectures besides x86: arm32, powerpc,
> s390, mips, etc all have a custom syscall.tbl file like x86 but
> don't have any asm/unistd.h installed in tools. If we want to
> support any of them in the future, we should start generating the
> files the same way we do for the kernel. There is already a copy
> of the syscall.tbl files in tools/perf/arch/*/entry/syscalls/syscall*.tbl
> and the arch/mips/kernel/syscalls/Makefile
> just not the corresponding scripts/syscallhdr.sh.

Thanks for the supplement, Arnd!

Using the syscall*.tbl files under tools/perf to generate unistd.h
headers is not a good idea for me.  These files are maintained within
tools/perf (mainly for perf beauty printing), but the generated
unistd.h headers are required by code outside of perf (e.g., libperf,
feature checks, etc.).

In fact, selftests already use dynamic headers (see [1]).  Seems to
me that we should apply the same approach to perf build.

Thanks,
Leo

[1] https://docs.kernel.org/dev-tools/kselftest.html#running-the-selftests-hotplug-tests-are-run-in-limited-mode

[PATCH v3 2/3] Revert "perf tools: Fix arm64 build by generating unistd_64.h"

[Leo Yan]

This reverts:

commit 8988c4b91945 ("perf tools: Fix in-source libperf build")
commit bfb713ea53c7 ("perf tools: Fix arm64 build by generating unistd_64.h")

Since we now have a static unistd_64.h for the arm64 build, there is no
need to generate unistd_64.h in libperf.  Revert all patches related to
generating unistd_64.h.

Signed-off-by: Leo Yan <leo.yan@arm.com>
---
 tools/lib/perf/Makefile    | 14 ++------------
 tools/perf/Makefile.config |  1 -
 2 files changed, 2 insertions(+), 13 deletions(-)

diff --git a/tools/lib/perf/Makefile b/tools/lib/perf/Makefile
index 7fbb50b74c00b3b99ac538821124e04bfbc6da6a..ffcfd777c45181960afc7505ef8f85d0b7ea7e8d 100644
--- a/tools/lib/perf/Makefile
+++ b/tools/lib/perf/Makefile
@@ -42,7 +42,6 @@ libdir_relative_SQ = $(subst ','\'',$(libdir_relative))
 TEST_ARGS := $(if $(V),-v)
 
 INCLUDES = \
--I$(OUTPUT)arch/$(SRCARCH)/include/generated/uapi \
 -I$(srctree)/tools/lib/perf/include \
 -I$(srctree)/tools/lib/ \
 -I$(srctree)/tools/include \
@@ -100,16 +99,7 @@ $(LIBAPI)-clean:
 	$(call QUIET_CLEAN, libapi)
 	$(Q)$(MAKE) -C $(LIB_DIR) O=$(OUTPUT) clean >/dev/null
 
-uapi-asm := $(OUTPUT)arch/$(SRCARCH)/include/generated/uapi/asm
-ifeq ($(SRCARCH),arm64)
-	syscall-y := $(uapi-asm)/unistd_64.h
-endif
-uapi-asm-generic:
-	$(if $(syscall-y),\
-		$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.asm-headers obj=$(uapi-asm) \
-		generic=include/uapi/asm-generic $(syscall-y),)
-
-$(LIBPERF_IN): uapi-asm-generic FORCE
+$(LIBPERF_IN): FORCE
 	$(Q)$(MAKE) $(build)=libperf
 
 $(LIBPERF_A): $(LIBPERF_IN)
@@ -130,7 +120,7 @@ all: fixdep
 clean: $(LIBAPI)-clean
 	$(call QUIET_CLEAN, libperf) $(RM) $(LIBPERF_A) \
                 *.o *~ *.a *.so *.so.$(VERSION) *.so.$(LIBPERF_VERSION) .*.d .*.cmd tests/*.o LIBPERF-CFLAGS $(LIBPERF_PC) \
-                $(TESTS_STATIC) $(TESTS_SHARED) $(syscall-y)
+                $(TESTS_STATIC) $(TESTS_SHARED)
 
 TESTS_IN = tests-in.o
 
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index bd9f4804d56babeeefd0c02758bebf1ff0c040dd..c97ed1190ea097c41ca83f2ace06c008cd7f0ca9 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -64,7 +64,6 @@ include $(srctree)/tools/scripts/Makefile.arch
 $(call detected_var,SRCARCH)
 
 CFLAGS += -I$(OUTPUT)arch/$(SRCARCH)/include/generated
-CFLAGS += -I$(OUTPUT)libperf/arch/$(SRCARCH)/include/generated/uapi
 
 # Additional ARCH settings for ppc
 ifeq ($(SRCARCH),powerpc)

-- 
2.34.1

[PATCH v3 3/3] tools headers: Don't check arm64's unistd.h

[Leo Yan]

The arm64 unistd.h in tools now diverges from the kernel header.
Comparing the two headers is pointless, remove the check.

Signed-off-by: Leo Yan <leo.yan@arm.com>
---
 tools/perf/check-headers.sh | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/perf/check-headers.sh b/tools/perf/check-headers.sh
index e0537f275da2f79ea9e05b91300aa1e2f996e9f1..da3aca87457fdc56c96d4184f2dee88dab026d98 100755
--- a/tools/perf/check-headers.sh
+++ b/tools/perf/check-headers.sh
@@ -54,7 +54,6 @@ declare -a FILES=(
   "arch/s390/include/uapi/asm/kvm.h"
   "arch/s390/include/uapi/asm/sie.h"
   "arch/arm64/include/uapi/asm/kvm.h"
-  "arch/arm64/include/uapi/asm/unistd.h"
   "arch/alpha/include/uapi/asm/errno.h"
   "arch/mips/include/asm/errno.h"
   "arch/mips/include/uapi/asm/errno.h"

-- 
2.34.1

Re: [PATCH v3 3/3] tools headers: Don't check arm64's unistd.h

[James Clark]

On 22/12/2025 6:06 pm, Leo Yan wrote:
> The arm64 unistd.h in tools now diverges from the kernel header.
> Comparing the two headers is pointless, remove the check.
> 
> Signed-off-by: Leo Yan <leo.yan@arm.com>
> ---
>   tools/perf/check-headers.sh | 1 -
>   1 file changed, 1 deletion(-)
> 
> diff --git a/tools/perf/check-headers.sh b/tools/perf/check-headers.sh
> index e0537f275da2f79ea9e05b91300aa1e2f996e9f1..da3aca87457fdc56c96d4184f2dee88dab026d98 100755
> --- a/tools/perf/check-headers.sh
> +++ b/tools/perf/check-headers.sh
> @@ -54,7 +54,6 @@ declare -a FILES=(
>     "arch/s390/include/uapi/asm/kvm.h"
>     "arch/s390/include/uapi/asm/sie.h"
>     "arch/arm64/include/uapi/asm/kvm.h"
> -  "arch/arm64/include/uapi/asm/unistd.h"

Isn't this _more_ of a special case for arm64 than continuing to do the 
consistency check like in v2? It seems like the desire for consistency 
isn't taking the whole tools/ picture into account and we end up adding 
more inconsistencies than just the regular static copy + diff check that 
we have for all the other headers.

>     "arch/alpha/include/uapi/asm/errno.h"
>     "arch/mips/include/asm/errno.h"
>     "arch/mips/include/uapi/asm/errno.h"
> 

Re: [PATCH v3 3/3] tools headers: Don't check arm64's unistd.h

[Leo Yan]

On Wed, Dec 24, 2025 at 01:51:33PM +0000, James Clark wrote:
> On 22/12/2025 6:06 pm, Leo Yan wrote:
> > The arm64 unistd.h in tools now diverges from the kernel header.
> > Comparing the two headers is pointless, remove the check.
> > 
> > Signed-off-by: Leo Yan <leo.yan@arm.com>
> > ---
> >   tools/perf/check-headers.sh | 1 -
> >   1 file changed, 1 deletion(-)
> > 
> > diff --git a/tools/perf/check-headers.sh b/tools/perf/check-headers.sh
> > index e0537f275da2f79ea9e05b91300aa1e2f996e9f1..da3aca87457fdc56c96d4184f2dee88dab026d98 100755
> > --- a/tools/perf/check-headers.sh
> > +++ b/tools/perf/check-headers.sh
> > @@ -54,7 +54,6 @@ declare -a FILES=(
> >     "arch/s390/include/uapi/asm/kvm.h"
> >     "arch/s390/include/uapi/asm/sie.h"
> >     "arch/arm64/include/uapi/asm/kvm.h"
> > -  "arch/arm64/include/uapi/asm/unistd.h"
> 
> Isn't this _more_ of a special case for arm64 than continuing to do the
> consistency check like in v2? It seems like the desire for consistency isn't
> taking the whole tools/ picture into account and we end up adding more
> inconsistencies than just the regular static copy + diff check that we have
> for all the other headers.

Ideally, the perf tool should not maintain UAPI headers. These headers
should be provided by the toolchain or generated dynamically.  From
this perspective, this patch is on the right way, as it avoids
maintaining special uAPI copies.

To be clear, I do not suggest removing all synced headers — only the
UAPI headers.

Thanks,
Leo