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

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

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

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

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