[PATCH 0/2] tools build: Fix arm64's unistd_64.h dependency

[PATCH 0/2] tools build: Fix arm64's unistd_64.h dependency

[Leo Yan]

Arm64's unistd.h is included in the tools build, but its dependent
header unistd_64.h is missing.  This results in only a partial set of UAPI
headers being available, forcing tools to generate unistd_64.h dynamically.

Because unistd.h is widely used across the tools directory, relying on a
dynamically generated header is fragile, especially when a tool builds in
multiple stages, each of which may include unistd.h.

This series addresses the issue by adding a generated unistd_64.h
directly to the tools tree, ensuring the header is available from the
start and eliminating build failures due to header dependency.

This series has been tested with Arm64 cross-compilation and confirmed
that the BPF feature is enabled in perf.  It also verifies libperf
in-source builds with applying this series.

Signed-off-by: Leo Yan <leo.yan@arm.com>
---
Leo Yan (2):
      tools headers: Add arm64's unistd_64.h
      Revert "perf tools: Fix arm64 build by generating unistd_64.h"

 tools/arch/arm64/include/uapi/asm/unistd_64.h | 330 ++++++++++++++++++++++++++
 tools/lib/perf/Makefile                       |  14 +-
 tools/perf/Makefile.config                    |   1 -
 3 files changed, 332 insertions(+), 13 deletions(-)
---
base-commit: 267c2e633af6e9461477bed91e428993f8b36ee8
change-id: 20251203-perf_fix_syscall_header-e280fa931d44

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

[PATCH 1/2] tools headers: Add arm64's unistd_64.h

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

We can fix perf build issue by generating unistd_64.h before feature
detection.  However, the problem persists whenever any program under
tools attempts to include unistd.h.

To address this reliably, and to keep the behavior consistent with other
architectures, we add a generated unistd_64.h header under arm64's uAPI
folder.  This 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_64.h | 330 ++++++++++++++++++++++++++
 1 file changed, 330 insertions(+)

diff --git a/tools/arch/arm64/include/uapi/asm/unistd_64.h b/tools/arch/arm64/include/uapi/asm/unistd_64.h
new file mode 100644
index 0000000000000000000000000000000000000000..7368e03c78e1f4b253f2ac7bbc4f913fcb2bf395
--- /dev/null
+++ b/tools/arch/arm64/include/uapi/asm/unistd_64.h
@@ -0,0 +1,330 @@
+#ifndef _UAPI_ASM_UNISTD_64_H
+#define _UAPI_ASM_UNISTD_64_H
+
+#define __NR_io_setup 0
+#define __NR_io_destroy 1
+#define __NR_io_submit 2
+#define __NR_io_cancel 3
+#define __NR_io_getevents 4
+#define __NR_setxattr 5
+#define __NR_lsetxattr 6
+#define __NR_fsetxattr 7
+#define __NR_getxattr 8
+#define __NR_lgetxattr 9
+#define __NR_fgetxattr 10
+#define __NR_listxattr 11
+#define __NR_llistxattr 12
+#define __NR_flistxattr 13
+#define __NR_removexattr 14
+#define __NR_lremovexattr 15
+#define __NR_fremovexattr 16
+#define __NR_getcwd 17
+#define __NR_lookup_dcookie 18
+#define __NR_eventfd2 19
+#define __NR_epoll_create1 20
+#define __NR_epoll_ctl 21
+#define __NR_epoll_pwait 22
+#define __NR_dup 23
+#define __NR_dup3 24
+#define __NR_fcntl 25
+#define __NR_inotify_init1 26
+#define __NR_inotify_add_watch 27
+#define __NR_inotify_rm_watch 28
+#define __NR_ioctl 29
+#define __NR_ioprio_set 30
+#define __NR_ioprio_get 31
+#define __NR_flock 32
+#define __NR_mknodat 33
+#define __NR_mkdirat 34
+#define __NR_unlinkat 35
+#define __NR_symlinkat 36
+#define __NR_linkat 37
+#define __NR_umount2 39
+#define __NR_mount 40
+#define __NR_pivot_root 41
+#define __NR_nfsservctl 42
+#define __NR_statfs 43
+#define __NR_fstatfs 44
+#define __NR_truncate 45
+#define __NR_ftruncate 46
+#define __NR_fallocate 47
+#define __NR_faccessat 48
+#define __NR_chdir 49
+#define __NR_fchdir 50
+#define __NR_chroot 51
+#define __NR_fchmod 52
+#define __NR_fchmodat 53
+#define __NR_fchownat 54
+#define __NR_fchown 55
+#define __NR_openat 56
+#define __NR_close 57
+#define __NR_vhangup 58
+#define __NR_pipe2 59
+#define __NR_quotactl 60
+#define __NR_getdents64 61
+#define __NR_lseek 62
+#define __NR_read 63
+#define __NR_write 64
+#define __NR_readv 65
+#define __NR_writev 66
+#define __NR_pread64 67
+#define __NR_pwrite64 68
+#define __NR_preadv 69
+#define __NR_pwritev 70
+#define __NR_sendfile 71
+#define __NR_pselect6 72
+#define __NR_ppoll 73
+#define __NR_signalfd4 74
+#define __NR_vmsplice 75
+#define __NR_splice 76
+#define __NR_tee 77
+#define __NR_readlinkat 78
+#define __NR_newfstatat 79
+#define __NR_fstat 80
+#define __NR_sync 81
+#define __NR_fsync 82
+#define __NR_fdatasync 83
+#define __NR_sync_file_range 84
+#define __NR_timerfd_create 85
+#define __NR_timerfd_settime 86
+#define __NR_timerfd_gettime 87
+#define __NR_utimensat 88
+#define __NR_acct 89
+#define __NR_capget 90
+#define __NR_capset 91
+#define __NR_personality 92
+#define __NR_exit 93
+#define __NR_exit_group 94
+#define __NR_waitid 95
+#define __NR_set_tid_address 96
+#define __NR_unshare 97
+#define __NR_futex 98
+#define __NR_set_robust_list 99
+#define __NR_get_robust_list 100
+#define __NR_nanosleep 101
+#define __NR_getitimer 102
+#define __NR_setitimer 103
+#define __NR_kexec_load 104
+#define __NR_init_module 105
+#define __NR_delete_module 106
+#define __NR_timer_create 107
+#define __NR_timer_gettime 108
+#define __NR_timer_getoverrun 109
+#define __NR_timer_settime 110
+#define __NR_timer_delete 111
+#define __NR_clock_settime 112
+#define __NR_clock_gettime 113
+#define __NR_clock_getres 114
+#define __NR_clock_nanosleep 115
+#define __NR_syslog 116
+#define __NR_ptrace 117
+#define __NR_sched_setparam 118
+#define __NR_sched_setscheduler 119
+#define __NR_sched_getscheduler 120
+#define __NR_sched_getparam 121
+#define __NR_sched_setaffinity 122
+#define __NR_sched_getaffinity 123
+#define __NR_sched_yield 124
+#define __NR_sched_get_priority_max 125
+#define __NR_sched_get_priority_min 126
+#define __NR_sched_rr_get_interval 127
+#define __NR_restart_syscall 128
+#define __NR_kill 129
+#define __NR_tkill 130
+#define __NR_tgkill 131
+#define __NR_sigaltstack 132
+#define __NR_rt_sigsuspend 133
+#define __NR_rt_sigaction 134
+#define __NR_rt_sigprocmask 135
+#define __NR_rt_sigpending 136
+#define __NR_rt_sigtimedwait 137
+#define __NR_rt_sigqueueinfo 138
+#define __NR_rt_sigreturn 139
+#define __NR_setpriority 140
+#define __NR_getpriority 141
+#define __NR_reboot 142
+#define __NR_setregid 143
+#define __NR_setgid 144
+#define __NR_setreuid 145
+#define __NR_setuid 146
+#define __NR_setresuid 147
+#define __NR_getresuid 148
+#define __NR_setresgid 149
+#define __NR_getresgid 150
+#define __NR_setfsuid 151
+#define __NR_setfsgid 152
+#define __NR_times 153
+#define __NR_setpgid 154
+#define __NR_getpgid 155
+#define __NR_getsid 156
+#define __NR_setsid 157
+#define __NR_getgroups 158
+#define __NR_setgroups 159
+#define __NR_uname 160
+#define __NR_sethostname 161
+#define __NR_setdomainname 162
+#define __NR_getrusage 165
+#define __NR_umask 166
+#define __NR_prctl 167
+#define __NR_getcpu 168
+#define __NR_gettimeofday 169
+#define __NR_settimeofday 170
+#define __NR_adjtimex 171
+#define __NR_getpid 172
+#define __NR_getppid 173
+#define __NR_getuid 174
+#define __NR_geteuid 175
+#define __NR_getgid 176
+#define __NR_getegid 177
+#define __NR_gettid 178
+#define __NR_sysinfo 179
+#define __NR_mq_open 180
+#define __NR_mq_unlink 181
+#define __NR_mq_timedsend 182
+#define __NR_mq_timedreceive 183
+#define __NR_mq_notify 184
+#define __NR_mq_getsetattr 185
+#define __NR_msgget 186
+#define __NR_msgctl 187
+#define __NR_msgrcv 188
+#define __NR_msgsnd 189
+#define __NR_semget 190
+#define __NR_semctl 191
+#define __NR_semtimedop 192
+#define __NR_semop 193
+#define __NR_shmget 194
+#define __NR_shmctl 195
+#define __NR_shmat 196
+#define __NR_shmdt 197
+#define __NR_socket 198
+#define __NR_socketpair 199
+#define __NR_bind 200
+#define __NR_listen 201
+#define __NR_accept 202
+#define __NR_connect 203
+#define __NR_getsockname 204
+#define __NR_getpeername 205
+#define __NR_sendto 206
+#define __NR_recvfrom 207
+#define __NR_setsockopt 208
+#define __NR_getsockopt 209
+#define __NR_shutdown 210
+#define __NR_sendmsg 211
+#define __NR_recvmsg 212
+#define __NR_readahead 213
+#define __NR_brk 214
+#define __NR_munmap 215
+#define __NR_mremap 216
+#define __NR_add_key 217
+#define __NR_request_key 218
+#define __NR_keyctl 219
+#define __NR_clone 220
+#define __NR_execve 221
+#define __NR_mmap 222
+#define __NR_fadvise64 223
+#define __NR_swapon 224
+#define __NR_swapoff 225
+#define __NR_mprotect 226
+#define __NR_msync 227
+#define __NR_mlock 228
+#define __NR_munlock 229
+#define __NR_mlockall 230
+#define __NR_munlockall 231
+#define __NR_mincore 232
+#define __NR_madvise 233
+#define __NR_remap_file_pages 234
+#define __NR_mbind 235
+#define __NR_get_mempolicy 236
+#define __NR_set_mempolicy 237
+#define __NR_migrate_pages 238
+#define __NR_move_pages 239
+#define __NR_rt_tgsigqueueinfo 240
+#define __NR_perf_event_open 241
+#define __NR_accept4 242
+#define __NR_recvmmsg 243
+#define __NR_wait4 260
+#define __NR_prlimit64 261
+#define __NR_fanotify_init 262
+#define __NR_fanotify_mark 263
+#define __NR_name_to_handle_at 264
+#define __NR_open_by_handle_at 265
+#define __NR_clock_adjtime 266
+#define __NR_syncfs 267
+#define __NR_setns 268
+#define __NR_sendmmsg 269
+#define __NR_process_vm_readv 270
+#define __NR_process_vm_writev 271
+#define __NR_kcmp 272
+#define __NR_finit_module 273
+#define __NR_sched_setattr 274
+#define __NR_sched_getattr 275
+#define __NR_renameat2 276
+#define __NR_seccomp 277
+#define __NR_getrandom 278
+#define __NR_memfd_create 279
+#define __NR_bpf 280
+#define __NR_execveat 281
+#define __NR_userfaultfd 282
+#define __NR_membarrier 283
+#define __NR_mlock2 284
+#define __NR_copy_file_range 285
+#define __NR_preadv2 286
+#define __NR_pwritev2 287
+#define __NR_pkey_mprotect 288
+#define __NR_pkey_alloc 289
+#define __NR_pkey_free 290
+#define __NR_statx 291
+#define __NR_io_pgetevents 292
+#define __NR_rseq 293
+#define __NR_kexec_file_load 294
+#define __NR_pidfd_send_signal 424
+#define __NR_io_uring_setup 425
+#define __NR_io_uring_enter 426
+#define __NR_io_uring_register 427
+#define __NR_open_tree 428
+#define __NR_move_mount 429
+#define __NR_fsopen 430
+#define __NR_fsconfig 431
+#define __NR_fsmount 432
+#define __NR_fspick 433
+#define __NR_pidfd_open 434
+#define __NR_clone3 435
+#define __NR_close_range 436
+#define __NR_openat2 437
+#define __NR_pidfd_getfd 438
+#define __NR_faccessat2 439
+#define __NR_process_madvise 440
+#define __NR_epoll_pwait2 441
+#define __NR_mount_setattr 442
+#define __NR_quotactl_fd 443
+#define __NR_landlock_create_ruleset 444
+#define __NR_landlock_add_rule 445
+#define __NR_landlock_restrict_self 446
+#define __NR_process_mrelease 448
+#define __NR_futex_waitv 449
+#define __NR_set_mempolicy_home_node 450
+#define __NR_cachestat 451
+#define __NR_fchmodat2 452
+#define __NR_map_shadow_stack 453
+#define __NR_futex_wake 454
+#define __NR_futex_wait 455
+#define __NR_futex_requeue 456
+#define __NR_statmount 457
+#define __NR_listmount 458
+#define __NR_lsm_get_self_attr 459
+#define __NR_lsm_set_self_attr 460
+#define __NR_lsm_list_modules 461
+#define __NR_mseal 462
+#define __NR_setxattrat 463
+#define __NR_getxattrat 464
+#define __NR_listxattrat 465
+#define __NR_removexattrat 466
+#define __NR_open_tree_attr 467
+#define __NR_file_getattr 468
+#define __NR_file_setattr 469
+
+#ifdef __KERNEL__
+#define __NR_syscalls 470
+#endif
+
+#endif /* _UAPI_ASM_UNISTD_64_H */

-- 
2.34.1

[PATCH 2/2] 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 6b62fea21a0ad1caf99d75d06fc29d2b05007931..b1e39fe0cf40ce1419b19a11daccc18853d5cfe6 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

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

[Ian Rogers]

On Thu, Dec 4, 2025 at 8:53 AM Leo Yan <leo.yan@arm.com> wrote:
>
> 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.

Could we generate the file and then compare the two? We do something
like this for empty-pmu-events.c here:
https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/pmu-events/Build?h=perf-tools-next#n49

Similarly, could we get rid of the unistd_64.h generation and just add
a build time validation test? Generating the file is painful in many
ways, as this series testifies.

Thanks,
Ian

> 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 6b62fea21a0ad1caf99d75d06fc29d2b05007931..b1e39fe0cf40ce1419b19a11daccc18853d5cfe6 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
>

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

[Leo Yan]

On Thu, Dec 04, 2025 at 10:19:59AM -0800, Ian Rogers wrote:
> On Thu, Dec 4, 2025 at 8:53 AM Leo Yan <leo.yan@arm.com> wrote:
> >
> > 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.
> 
> Could we generate the file and then compare the two? We do something
> like this for empty-pmu-events.c here:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/pmu-events/Build?h=perf-tools-next#n49
> 
> Similarly, could we get rid of the unistd_64.h generation and just add
> a build time validation test? Generating the file is painful in many
> ways, as this series testifies.

Thanks for suggestions!

I had a question: why we need to maintain unistd.h particually in
./tools folder?  This header is a standard C header and should be
provided by toolchain instead.  Due to multiple copies, it is a bit mess
the programs might include unpurposed one.

I went through the history and found:

  commit 34b009cfde2b ("tools include: Grab copies of arm64 dependent unistd.h files")

It introduces the header unistd.h for generating system call table.

Afterwards,

  commit cb8197db8c09 ("perf tools arm64: Use syscall table")

unistd.h headers are not used to generate syscall table anymore.  Since
then, syscall tables are maintained in
tools/perf/arch/*/entry/syscalls/syscall*.tbl for each arch.

To verify this, I did a quick try with removing x86 and arm64 headers:

  tools/arch/arm64/include/uapi/asm/unistd.h
  tools/arch/x86/include/uapi/asm/unistd.h
  tools/arch/x86/include/uapi/asm/unistd_32.h
  tools/arch/x86/include/uapi/asm/unistd_64.h

I run the linux-tools-container-builds and confirmed all x86 and arm64
building tests pass and did not see any failure.

For a neat fix, I think we can remove all unistd.h headers:

  $ ls tools/arch/*/include/uapi/asm/unistd*
  tools/arch/arc/include/uapi/asm/unistd.h
  tools/arch/hexagon/include/uapi/asm/unistd.h
  tools/arch/riscv/include/uapi/asm/unistd.h
  tools/arch/x86/include/uapi/asm/unistd_64.h
  tools/arch/arm64/include/uapi/asm/unistd.h
  tools/arch/loongarch/include/uapi/asm/unistd.h
  tools/arch/x86/include/uapi/asm/unistd_32.h
  tools/arch/x86/include/uapi/asm/unistd.h

Any concern?  I would get maintainers's confirmation before proceeding.

Thanks,
Leo

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

[Ian Rogers]

On Fri, Dec 5, 2025 at 8:21 AM Leo Yan <leo.yan@arm.com> wrote:
>
> On Thu, Dec 04, 2025 at 10:19:59AM -0800, Ian Rogers wrote:
> > On Thu, Dec 4, 2025 at 8:53 AM Leo Yan <leo.yan@arm.com> wrote:
> > >
> > > 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.
> >
> > Could we generate the file and then compare the two? We do something
> > like this for empty-pmu-events.c here:
> > https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/pmu-events/Build?h=perf-tools-next#n49
> >
> > Similarly, could we get rid of the unistd_64.h generation and just add
> > a build time validation test? Generating the file is painful in many
> > ways, as this series testifies.
>
> Thanks for suggestions!
>
> I had a question: why we need to maintain unistd.h particually in
> ./tools folder?  This header is a standard C header and should be
> provided by toolchain instead.  Due to multiple copies, it is a bit mess
> the programs might include unpurposed one.
>
> I went through the history and found:
>
>   commit 34b009cfde2b ("tools include: Grab copies of arm64 dependent unistd.h files")
>
> It introduces the header unistd.h for generating system call table.
>
> Afterwards,
>
>   commit cb8197db8c09 ("perf tools arm64: Use syscall table")
>
> unistd.h headers are not used to generate syscall table anymore.  Since
> then, syscall tables are maintained in
> tools/perf/arch/*/entry/syscalls/syscall*.tbl for each arch.
>
> To verify this, I did a quick try with removing x86 and arm64 headers:
>
>   tools/arch/arm64/include/uapi/asm/unistd.h
>   tools/arch/x86/include/uapi/asm/unistd.h
>   tools/arch/x86/include/uapi/asm/unistd_32.h
>   tools/arch/x86/include/uapi/asm/unistd_64.h
>
> I run the linux-tools-container-builds and confirmed all x86 and arm64
> building tests pass and did not see any failure.
>
> For a neat fix, I think we can remove all unistd.h headers:
>
>   $ ls tools/arch/*/include/uapi/asm/unistd*
>   tools/arch/arc/include/uapi/asm/unistd.h
>   tools/arch/hexagon/include/uapi/asm/unistd.h
>   tools/arch/riscv/include/uapi/asm/unistd.h
>   tools/arch/x86/include/uapi/asm/unistd_64.h
>   tools/arch/arm64/include/uapi/asm/unistd.h
>   tools/arch/loongarch/include/uapi/asm/unistd.h
>   tools/arch/x86/include/uapi/asm/unistd_32.h
>   tools/arch/x86/include/uapi/asm/unistd.h
>
> Any concern?  I would get maintainers's confirmation before proceeding.

Thanks Leo! The tools/include directory is a concern for me as the use
of it is pretty unstructured. For example, what does <linux/types.h>
refer to? In the perf build it is actually the kernel version of
types.h rather than the UAPI version, despite perf being a user land
tool. In general this is necessary to get other kernel headers to work
(say list.h). I think it brings about a number of concerns, one being
around licensing. My preference would be to make tools/include an
explicit dependency, like libperf and libsubcmd. It would have
associated header files you could install and depend upon, placing
those header files onto your include path from the install directory.
Things in tools/include with different licenses can have different lib
variants so that it is clear what license is being linked against -
generally GPLv2 vs GPLv2+linux syscall exception.

Given that we're mixing kernel and UAPI headers there is a need for
the headers to be hermetic. We can't just use parts of headers from
the kernel, some from UAPI, some from the latest kernel tree and some
from whatever libc is on the system. There are differences in the use
of things like u64 vs __u64 that will all too easily give build
errors, especially when building against an older libc.

Arnaldo did make some moves to clean up tools/include with patches like:
https://lore.kernel.org/lkml/Ze93VPYpegMMt5kk@x1/
That mention a breakage I caused ARM64/James around tools/include (I
mention the library idea above again, sorry I'm a broken record):
https://lore.kernel.org/lkml/CAP-5=fWZVrpRufO4w-S4EcSi9STXcTAN2ERLwTSN7yrSSA-otQ@mail.gmail.com/
I think the breakage shows things need to be hermetic, which may mean
we need unistd_64.h. I think Arnaldo's moving of fs.h shows that less
in the tools/include directory is better and supported by the
maintainers.

Thanks for doing the build testing! Doing a simpler grep:
```
$ grep -r "asm/unistd" tools/include tools/perf tools/lib
tools/perf/check-headers.sh:  "arch/x86/include/uapi/asm/unistd.h"
tools/perf/check-headers.sh:  "arch/arm64/include/uapi/asm/unistd.h"
tools/lib/bpf/bpf.c:#include <asm/unistd.h>
tools/lib/bpf/libbpf.c:#include <asm/unistd.h>
```
I think unistd.h is needed to make things hermetic for libbpf :-( If
we can make libbpf use just the regular unistd.h then life would be
good. My experience is that libbpf tends to like the kernel way of
doing things a bit too much - <rant>they have the IS_ERR/ERR_PTR
antipattern rather than just using errno, as because you know this is
user land and that's how stuff normally gets done and we can make
pointers type safe. Also don't try adding comments to their syscall
APIs unless you enjoy being called "wrong" a lot with no constructive
feedback. </rant>. Anyway, I think getting rid of unistd.h is a good
thing but it will probably break perf's build that invokes libbpf's
build because libbpf will be mixing kernel and old libc headers on one
of the maintainers build test platforms (likely an old one) where the
type collisions yield compile time errors. To avoid that I'd suggest
making libbpf not use asm/unistd.h as a first step. We could get lucky
with something non-hermetic, but it wouldn't be my preference.

Thanks,
Ian

> Thanks,
> Leo

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

[Leo Yan]

Hi Ian,

On Fri, Dec 05, 2025 at 09:16:32AM -0800, Ian Rogers wrote:

[...]

> > For a neat fix, I think we can remove all unistd.h headers:
> >
> >   $ ls tools/arch/*/include/uapi/asm/unistd*
> >   tools/arch/arc/include/uapi/asm/unistd.h
> >   tools/arch/hexagon/include/uapi/asm/unistd.h
> >   tools/arch/riscv/include/uapi/asm/unistd.h
> >   tools/arch/x86/include/uapi/asm/unistd_64.h
> >   tools/arch/arm64/include/uapi/asm/unistd.h
> >   tools/arch/loongarch/include/uapi/asm/unistd.h
> >   tools/arch/x86/include/uapi/asm/unistd_32.h
> >   tools/arch/x86/include/uapi/asm/unistd.h
> >
> > Any concern?  I would get maintainers's confirmation before proceeding.
> 
> Thanks Leo! The tools/include directory is a concern for me as the use
> of it is pretty unstructured. For example, what does <linux/types.h>
> refer to?

I understand your concern.

For my current work, I would like to constraint to unistd.h headers
only, now this is breaking BPF skeleton building on Arm64.

I did not observe other building failures, so we can polish other
headers later.

> Thanks for doing the build testing! Doing a simpler grep:
> ```
> $ grep -r "asm/unistd" tools/include tools/perf tools/lib
> tools/perf/check-headers.sh:  "arch/x86/include/uapi/asm/unistd.h"
> tools/perf/check-headers.sh:  "arch/arm64/include/uapi/asm/unistd.h"
> tools/lib/bpf/bpf.c:#include <asm/unistd.h>
> tools/lib/bpf/libbpf.c:#include <asm/unistd.h>
> ```
> I think unistd.h is needed to make things hermetic for libbpf :-( ...
> Anyway, I think getting rid of unistd.h is a good
> thing but it will probably break perf's build that invokes libbpf's
> build because libbpf will be mixing kernel and old libc headers on one
> of the maintainers build test platforms (likely an old one) where the
> type collisions yield compile time errors. To avoid that I'd suggest
> making libbpf not use asm/unistd.h as a first step. We could get lucky
> with something non-hermetic, but it wouldn't be my preference.

Based on my test, perf (including libbpf) builds successfully without
relying on the unistd.h headers under tools/arch.

To verify which "unistd.h" headers are actually included, I searched
dependencies recorded in .cmd files:

  grep -r --include="*.cmd" "unistd.h" /data_nvme1n1/niayan01/upstream/build/

See the complete log: https://termbin.com/9w85

The mentioned libbpf building includes "unistd.h" headers from the toolchain
and can build successfully.  I verified with two GCC toolchains:

  # aarch64-linux-gnu-gcc --version
  aarch64-linux-gnu-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
  Copyright (C) 2019 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

  # aarch64-linux-gnu-gcc --version
  aarch64-linux-gnu-gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0
  Copyright (C) 2023 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

As a side topic, given libbpf is maintained on github and can support
standalone build [1], we should have confidence that it is not dependent on
tools' headers.

I still think removing the unistd.h headers from tools is the right thing to
do, and based on test, it does not break perf building.

Thanks,
Leo

[1] https://github.com/libbpf/libbpf?tab=readme-ov-file#building-libbpf

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

[Ian Rogers]

On Tue, Dec 9, 2025 at 2:49 AM Leo Yan <leo.yan@arm.com> wrote:
>
> Hi Ian,
>
> On Fri, Dec 05, 2025 at 09:16:32AM -0800, Ian Rogers wrote:
>
> [...]
>
> > > For a neat fix, I think we can remove all unistd.h headers:
> > >
> > >   $ ls tools/arch/*/include/uapi/asm/unistd*
> > >   tools/arch/arc/include/uapi/asm/unistd.h
> > >   tools/arch/hexagon/include/uapi/asm/unistd.h
> > >   tools/arch/riscv/include/uapi/asm/unistd.h
> > >   tools/arch/x86/include/uapi/asm/unistd_64.h
> > >   tools/arch/arm64/include/uapi/asm/unistd.h
> > >   tools/arch/loongarch/include/uapi/asm/unistd.h
> > >   tools/arch/x86/include/uapi/asm/unistd_32.h
> > >   tools/arch/x86/include/uapi/asm/unistd.h
> > >
> > > Any concern?  I would get maintainers's confirmation before proceeding.
> >
> > Thanks Leo! The tools/include directory is a concern for me as the use
> > of it is pretty unstructured. For example, what does <linux/types.h>
> > refer to?
>
> I understand your concern.
>
> For my current work, I would like to constraint to unistd.h headers
> only, now this is breaking BPF skeleton building on Arm64.
>
> I did not observe other building failures, so we can polish other
> headers later.
>
> > Thanks for doing the build testing! Doing a simpler grep:
> > ```
> > $ grep -r "asm/unistd" tools/include tools/perf tools/lib
> > tools/perf/check-headers.sh:  "arch/x86/include/uapi/asm/unistd.h"
> > tools/perf/check-headers.sh:  "arch/arm64/include/uapi/asm/unistd.h"
> > tools/lib/bpf/bpf.c:#include <asm/unistd.h>
> > tools/lib/bpf/libbpf.c:#include <asm/unistd.h>
> > ```
> > I think unistd.h is needed to make things hermetic for libbpf :-( ...
> > Anyway, I think getting rid of unistd.h is a good
> > thing but it will probably break perf's build that invokes libbpf's
> > build because libbpf will be mixing kernel and old libc headers on one
> > of the maintainers build test platforms (likely an old one) where the
> > type collisions yield compile time errors. To avoid that I'd suggest
> > making libbpf not use asm/unistd.h as a first step. We could get lucky
> > with something non-hermetic, but it wouldn't be my preference.
>
> Based on my test, perf (including libbpf) builds successfully without
> relying on the unistd.h headers under tools/arch.
>
> To verify which "unistd.h" headers are actually included, I searched
> dependencies recorded in .cmd files:
>
>   grep -r --include="*.cmd" "unistd.h" /data_nvme1n1/niayan01/upstream/build/
>
> See the complete log: https://termbin.com/9w85
>
> The mentioned libbpf building includes "unistd.h" headers from the toolchain
> and can build successfully.  I verified with two GCC toolchains:
>
>   # aarch64-linux-gnu-gcc --version
>   aarch64-linux-gnu-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
>   Copyright (C) 2019 Free Software Foundation, Inc.
>   This is free software; see the source for copying conditions.  There is NO
>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
>   # aarch64-linux-gnu-gcc --version
>   aarch64-linux-gnu-gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0
>   Copyright (C) 2023 Free Software Foundation, Inc.
>   This is free software; see the source for copying conditions.  There is NO
>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> As a side topic, given libbpf is maintained on github and can support
> standalone build [1], we should have confidence that it is not dependent on
> tools' headers.

The github project does things differently and has copied headers into
itself to make things work. It doesn't copy unistd.h:
https://github.com/libbpf/libbpf/tree/master/include/asm
but I'm not sure that means anything beyond the BPF buildbot not needing it.

> I still think removing the unistd.h headers from tools is the right thing to
> do, and based on test, it does not break perf building.

I think this is the getting lucky case I referred to :-) I can imagine
in the build environment I'm in, needing to revert the change to make
sure the headers remain hermetic. I suspect the perf on old Linux
build checks will also face a similar problem.

Thanks,
Ian

> Thanks,
> Leo
>
> [1] https://github.com/libbpf/libbpf?tab=readme-ov-file#building-libbpf