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

[Leo Yan <leo.yan@arm.com>]

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