[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <58e432e4-5825-4f2e-9aba-29be63eac56f@linaro.org>
Date: Wed, 24 Dec 2025 13:47:51 +0000
From: James Clark <james.clark@...aro.org>
To: Leo Yan <leo.yan@....com>, Arnd Bergmann <arnd@...db.de>
Cc: linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Namhyung Kim <namhyung@...nel.org>, Jiri Olsa <jolsa@...nel.org>,
Ian Rogers <irogers@...gle.com>, Adrian Hunter <adrian.hunter@...el.com>
Subject: Re: [PATCH v3 1/3] tools headers: Go back to include
asm-generic/unistd.h for arm64
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@....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>
>
Powered by blists - more mailing lists