When cross-compiling perf with BPF enabled, Clang is invoked during the
build. Some cross-compilation environments require additional compiler
options, such as `--sysroot` or custom include paths.

This patch introduces a new Make variable, `EXTRA_BPF_FLAGS`. During BPF
skeleton builds, it appends user-provided options to `CLANG_OPTIONS`,
allowing extra Clang flags to be set without modifying Makefile.perf
directly.

Example usage:
    EXTRA_BPF_FLAGS="--sysroot=$SYSROOT"
    make perf ARCH="$ARCH" EXTRA_BPF_FLAGS="$EXTRA_BPF_FLAGS"

Change history:
  v2:
    - Rename EXTRA_CLANG_FLAGS to EXTRA_BPF_FLAGS
    - Update commit message
  v1:
    - Introduce EXTRA_CLANG_FLAGS to allow passing extra Clang options

Signed-off-by: hupu <hupu.gm@gmail.com>
---
 tools/perf/Makefile.perf | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 47c906b807ef..f1f2efdbab8c 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -1249,6 +1249,11 @@ else
 	$(Q)cp "$(VMLINUX_H)" $@
 endif
 
+# Allow users to specify additional Clang options (e.g. --sysroot)
+# when cross-compiling BPF skeletons, enabling more flexible
+# build configurations.
+CLANG_OPTIONS += $(EXTRA_BPF_FLAGS)
+
 $(SKEL_TMP_OUT)/%.bpf.o: $(OUTPUT)PERF-VERSION-FILE util/bpf_skel/perf_version.h | $(SKEL_TMP_OUT)
 $(SKEL_TMP_OUT)/%.bpf.o: util/bpf_skel/%.bpf.c $(LIBBPF) $(SKEL_OUT)/vmlinux.h
 	$(QUIET_CLANG)$(CLANG) -g -O2 -fno-stack-protector --target=bpf \
-- 
2.43.0

On Mon, Oct 20, 2025 at 10:40:49AM +0800, hupu wrote:
> When cross-compiling perf with BPF enabled, Clang is invoked during the
> build. Some cross-compilation environments require additional compiler
> options, such as `--sysroot` or custom include paths.
> 
> This patch introduces a new Make variable, `EXTRA_BPF_FLAGS`. During BPF
> skeleton builds, it appends user-provided options to `CLANG_OPTIONS`,
> allowing extra Clang flags to be set without modifying Makefile.perf
> directly.
> 
> Example usage:
>     EXTRA_BPF_FLAGS="--sysroot=$SYSROOT"
>     make perf ARCH="$ARCH" EXTRA_BPF_FLAGS="$EXTRA_BPF_FLAGS"

Why not just:

  make perf ARCH="arm64" EXTRA_BPF_FLAGS="--sysroot=..."

> 
> Change history:
>   v2:
>     - Rename EXTRA_CLANG_FLAGS to EXTRA_BPF_FLAGS
>     - Update commit message
>   v1:
>     - Introduce EXTRA_CLANG_FLAGS to allow passing extra Clang options
> 
> Signed-off-by: hupu <hupu.gm@gmail.com>

Leo, are you ok with this?

> ---
>  tools/perf/Makefile.perf | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> index 47c906b807ef..f1f2efdbab8c 100644
> --- a/tools/perf/Makefile.perf
> +++ b/tools/perf/Makefile.perf
> @@ -1249,6 +1249,11 @@ else
>  	$(Q)cp "$(VMLINUX_H)" $@
>  endif
>  
> +# Allow users to specify additional Clang options (e.g. --sysroot)
> +# when cross-compiling BPF skeletons, enabling more flexible
> +# build configurations.

Can you please move this comment or add new one at the top of the file
along with EXTRA_CFLAGS?

Thanks,
Namhyung

> +CLANG_OPTIONS += $(EXTRA_BPF_FLAGS)
> +
>  $(SKEL_TMP_OUT)/%.bpf.o: $(OUTPUT)PERF-VERSION-FILE util/bpf_skel/perf_version.h | $(SKEL_TMP_OUT)
>  $(SKEL_TMP_OUT)/%.bpf.o: util/bpf_skel/%.bpf.c $(LIBBPF) $(SKEL_OUT)/vmlinux.h
>  	$(QUIET_CLANG)$(CLANG) -g -O2 -fno-stack-protector --target=bpf \
> -- 
> 2.43.0
>

On Mon, Oct 20, 2025 at 01:16:46PM +0900, Namhyung Kim wrote:

[...]

> On Mon, Oct 20, 2025 at 10:40:49AM +0800, hupu wrote:
> > When cross-compiling perf with BPF enabled, Clang is invoked during the
> > build. Some cross-compilation environments require additional compiler
> > options, such as `--sysroot` or custom include paths.

[...]

> Leo, are you ok with this?

To be clear, now we are not talking cross build for perf program or any
targeting a CPU arch, it is a build failure for eBPF program.

This patch does not make clear why we cannot build eBPF program in
self-contained way. E.g., after installed kernel headers, why Makefile
misses to include installed headers when build eBPF program.

I am not saying we cannot specify an external sysroot path, but before
proceed that, we should make sure the build can work with self-contained
headers.

Thanks,
Leo

Hi Leo,
Thank you for your reply and for taking the time to discuss this in detail.

On Mon, Oct 20, 2025 at 6:15 PM Leo Yan <leo.yan@arm.com> wrote:
>
> On Mon, Oct 20, 2025 at 01:16:46PM +0900, Namhyung Kim wrote:
>
> [...]
>
> > On Mon, Oct 20, 2025 at 10:40:49AM +0800, hupu wrote:
> > > When cross-compiling perf with BPF enabled, Clang is invoked during the
> > > build. Some cross-compilation environments require additional compiler
> > > options, such as `--sysroot` or custom include paths.
>
> [...]
>
> > Leo, are you ok with this?
>
> To be clear, now we are not talking cross build for perf program or any
> targeting a CPU arch, it is a build failure for eBPF program.
>

I’d like to clarify the background and scenario once more:
I’m building an SDK that includes a cross-compilation toolchain for
the target architecture along with a copy of the kernel source tree.
The goal is to make this SDK usable on any host system to build
software, including perf with eBPF enabled, without requiring the host
to install any additional packages. This is a common requirement in
embedded environments, where we often cannot control or modify the
host system setup.


On Wed, Oct 15, 2025 at 5:30 PM Leo Yan <leo.yan@arm.com> wrote:
>
> Have you installed the GCC cross packages ?
>
>  $ sudo apt-get install gcc-aarch64-linux-gnu g++-aarch64-linux-gnu
>  $ sudo apt-get install libc6-dev-aarch64-cross linux-libc-dev-aarch64-cross
>  $ sudo apt-get install libc6-dev-arm64-cross linux-libc-dev-arm64-cross
>
> My understanding is arm64 cross compilation tries to find headers in the
> path /usr/aarch64-linux-gnu/include/ (I confirmed this on Ubuntu/Debian
> distros).  After install GCC cross packages, the headers should appear
> in the folder.
>

As you mentioned earlier, installing the GCC cross packages on the
host does allow perf to be cross-built successfully. This works in my
current setup (Ubuntu host kernel 6.14, SDK kernel source 6.18).

However, this approach has two key drawbacks:
a) Limited portability
If the SDK is moved to a different host, these packages must be
installed again for it to work, breaking the “plug-and-play” goal and
increasing deployment complexity.
b) Kernel version mismatch risk
The headers from these packages are determined by the kernel version
in the host’s distribution repository, not the kernel version in the
SDK. For example, the host apt repository might ship headers from
kernel 5.0 while the SDK contains kernel 6.18; differences in UAPI
files (e.g., linux/bpf.h) could cause eBPF programs to fail to build
due to missing APIs or structure changes. This risk is greater with
fast-evolving subsystems like eBPF, even if it does not happen in my
current environment.

This is why I don’t consider relying on host-installed packages as an
optimal solution for my case.


> This patch does not make clear why we cannot build eBPF program in
> self-contained way. E.g., after installed kernel headers, why Makefile
> misses to include installed headers when build eBPF program.
>

I may not have explained myself clearly. As noted above, installing
the headers you mentioned does allow perf to build successfully, but
this is not the approach I ideally want, and it is not the most
suitable option for my current context.

The aim of my patch is to explicitly direct the build system to use
the SDK’s own header files (via --sysroot or an additional -I path),
ensuring that:
a) The build works without installing any host packages;
b) The headers used always match the SDK’s kernel version, eliminating
potential version mismatch problems.

I believe this approach meets the principle of self-contained builds
and aligns well with real-world embedded development needs.

In addition, allowing additional parameters to be passed to clang via
EXTRA_BPF_FLAGS would provide greater flexibility in the build
process.

Looking forward to further discussion.

Thanks,
hupu

Hi hupu,

On Mon, Oct 20, 2025 at 08:51:52PM +0800, hupu wrote:

[...]

> > To be clear, now we are not talking cross build for perf program or any
> > targeting a CPU arch, it is a build failure for eBPF program.
> >
> 
> I’d like to clarify the background and scenario once more:
> I’m building an SDK that includes a cross-compilation toolchain for
> the target architecture along with a copy of the kernel source tree.

I am not preventing to use toolchains in you mentioned SDK.  I just
prefer to give priority the headers provided by the kernel source.

Seems to me, a more reasonable series would be:

 - Fix the eBPF program build with using self-contained headers;
 - Extend to support external headers.

Thanks,
Leo

It is worth noting that this is not a special requirement unique to my
case, but rather a common need in embedded development scenarios.

Thanks,
hupu

On Mon, Oct 20, 2025 at 8:51 PM hupu <hupu.gm@gmail.com> wrote:
>
> Hi Leo,
> Thank you for your reply and for taking the time to discuss this in detail.
>
> On Mon, Oct 20, 2025 at 6:15 PM Leo Yan <leo.yan@arm.com> wrote:
> >
> > On Mon, Oct 20, 2025 at 01:16:46PM +0900, Namhyung Kim wrote:
> >
> > [...]
> >
> > > On Mon, Oct 20, 2025 at 10:40:49AM +0800, hupu wrote:
> > > > When cross-compiling perf with BPF enabled, Clang is invoked during the
> > > > build. Some cross-compilation environments require additional compiler
> > > > options, such as `--sysroot` or custom include paths.
> >
> > [...]
> >
> > > Leo, are you ok with this?
> >
> > To be clear, now we are not talking cross build for perf program or any
> > targeting a CPU arch, it is a build failure for eBPF program.
> >
>
> I’d like to clarify the background and scenario once more:
> I’m building an SDK that includes a cross-compilation toolchain for
> the target architecture along with a copy of the kernel source tree.
> The goal is to make this SDK usable on any host system to build
> software, including perf with eBPF enabled, without requiring the host
> to install any additional packages. This is a common requirement in
> embedded environments, where we often cannot control or modify the
> host system setup.
>
>
> On Wed, Oct 15, 2025 at 5:30 PM Leo Yan <leo.yan@arm.com> wrote:
> >
> > Have you installed the GCC cross packages ?
> >
> >  $ sudo apt-get install gcc-aarch64-linux-gnu g++-aarch64-linux-gnu
> >  $ sudo apt-get install libc6-dev-aarch64-cross linux-libc-dev-aarch64-cross
> >  $ sudo apt-get install libc6-dev-arm64-cross linux-libc-dev-arm64-cross
> >
> > My understanding is arm64 cross compilation tries to find headers in the
> > path /usr/aarch64-linux-gnu/include/ (I confirmed this on Ubuntu/Debian
> > distros).  After install GCC cross packages, the headers should appear
> > in the folder.
> >
>
> As you mentioned earlier, installing the GCC cross packages on the
> host does allow perf to be cross-built successfully. This works in my
> current setup (Ubuntu host kernel 6.14, SDK kernel source 6.18).
>
> However, this approach has two key drawbacks:
> a) Limited portability
> If the SDK is moved to a different host, these packages must be
> installed again for it to work, breaking the “plug-and-play” goal and
> increasing deployment complexity.
> b) Kernel version mismatch risk
> The headers from these packages are determined by the kernel version
> in the host’s distribution repository, not the kernel version in the
> SDK. For example, the host apt repository might ship headers from
> kernel 5.0 while the SDK contains kernel 6.18; differences in UAPI
> files (e.g., linux/bpf.h) could cause eBPF programs to fail to build
> due to missing APIs or structure changes. This risk is greater with
> fast-evolving subsystems like eBPF, even if it does not happen in my
> current environment.
>
> This is why I don’t consider relying on host-installed packages as an
> optimal solution for my case.
>
>
> > This patch does not make clear why we cannot build eBPF program in
> > self-contained way. E.g., after installed kernel headers, why Makefile
> > misses to include installed headers when build eBPF program.
> >
>
> I may not have explained myself clearly. As noted above, installing
> the headers you mentioned does allow perf to build successfully, but
> this is not the approach I ideally want, and it is not the most
> suitable option for my current context.
>
> The aim of my patch is to explicitly direct the build system to use
> the SDK’s own header files (via --sysroot or an additional -I path),
> ensuring that:
> a) The build works without installing any host packages;
> b) The headers used always match the SDK’s kernel version, eliminating
> potential version mismatch problems.
>
> I believe this approach meets the principle of self-contained builds
> and aligns well with real-world embedded development needs.
>
> In addition, allowing additional parameters to be passed to clang via
> EXTRA_BPF_FLAGS would provide greater flexibility in the build
> process.
>
> Looking forward to further discussion.
>
> Thanks,
> hupu

Hi Leo,
Thank you for your reply.

> > > To be clear, now we are not talking cross build for perf program or any
> > > targeting a CPU arch, it is a build failure for eBPF program.
> > >
> >
> > I’d like to clarify the background and scenario once more:
> > I’m building an SDK that includes a cross-compilation toolchain for
> > the target architecture along with a copy of the kernel source tree.
>
> I am not preventing to use toolchains in you mentioned SDK.  I just
> prefer to give priority the headers provided by the kernel source.
>
> Seems to me, a more reasonable series would be:
>
>  - Fix the eBPF program build with using self-contained headers;
>  - Extend to support external headers.
>

I’m sorry, but I believe there may be some misunderstanding between us
regarding the term "self-contained headers". May I ask what exactly
you mean by "self-contained headers" in your message above?

From my perspective, it could refer to one of the following:

a) The header files installed via the following apt commands:
> Have you installed the GCC cross packages ?
>
>  $ sudo apt-get install gcc-aarch64-linux-gnu g++-aarch64-linux-gnu
>  $ sudo apt-get install libc6-dev-aarch64-cross linux-libc-dev-aarch64-cross
>  $ sudo apt-get install libc6-dev-arm64-cross linux-libc-dev-arm64-cross

b) The headers from the Linux kernel source tree.
c) The headers located under the sysroot path of the cross-toolchain.

At the moment, I’m not entirely sure which one you’re referring to,
and this uncertainty might have led to some misalignment in our
previous discussion. Therefore, it would be very helpful if you could
kindly clarify this point.


Thanks,
hupu

Hi Leo and Namhyung,
Sorry for the late response, and thanks for the guidance on
prioritizing self-contained headers from the kernel source.


> > > To be clear, now we are not talking cross build for perf program or any
> > > targeting a CPU arch, it is a build failure for eBPF program.
> > >
> >
> > I’d like to clarify the background and scenario once more:
> > I’m building an SDK that includes a cross-compilation toolchain for
> > the target architecture along with a copy of the kernel source tree.
>
> I am not preventing to use toolchains in you mentioned SDK.  I just
> prefer to give priority the headers provided by the kernel source.
>
> Seems to me, a more reasonable series would be:
>
>  - Fix the eBPF program build with using self-contained headers;
>  - Extend to support external headers.
>


I added the following diagnostic output to Makefile.perf to print
CLANG_OPTIONS, BPF_INCLUDE, and TOOLS_UAPI_INCLUDE during compilation,
to identify the header search paths used when building the eBPF
program.


diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 47c906b807ef..33fe2d8f16c6 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -1249,6 +1249,12 @@ else
        $(Q)cp "$(VMLINUX_H)" $@
 endif

+$(warning AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
+$(warning CLANG_OPTIONS: $(CLANG_OPTIONS))
+$(warning BPF_INCLUDE: $(BPF_INCLUDE))
+$(warning TOOLS_UAPI_INCLUDE: $(TOOLS_UAPI_INCLUDE))
+$(warning AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA)
+
 $(SKEL_TMP_OUT)/%.bpf.o: $(OUTPUT)PERF-VERSION-FILE
util/bpf_skel/perf_version.h | $(SKEL_TMP_OUT)
 $(SKEL_TMP_OUT)/%.bpf.o: util/bpf_skel/%.bpf.c $(LIBBPF) $(SKEL_OUT)/vmlinux.h
        $(QUIET_CLANG)$(CLANG) -g -O2 -fno-stack-protector --target=bpf \


The compilation output is as follows:


Makefile.perf:1252: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Makefile.perf:1253: CLANG_OPTIONS: -Wall -Werror
Makefile.perf:1254: BPF_INCLUDE:
-I/home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/..
-I/home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/include
-idirafter /usr/lib/llvm-18/lib/clang/18/include -idirafter
/usr/local/include -idirafter /usr/include
Makefile.perf:1255: TOOLS_UAPI_INCLUDE:
-I/home/hupu/work/code/explore/linux-mainline/tools/include/uapi
Makefile.perf:1256: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA


From the above BPF_INCLUDE and TOOLS_UAPI_INCLUDE prints, perf was not
prioritizing the kernel’s self-contained headers when compiling the
eBPF program.

I then added KHDR_INCLUDES to BPF_INCLUDE, pointing it to the kernel’s
self-contained header directory so that the build prefers headers
provided by the kernel.


diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 47c906b807ef..65c6e871988b 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -1202,7 +1202,8 @@ endif

 CLANG_OPTIONS = -Wall
 CLANG_SYS_INCLUDES = $(call get_sys_includes,$(CLANG),$(CLANG_TARGET_ARCH))
-BPF_INCLUDE := -I$(SKEL_TMP_OUT)/.. -I$(LIBBPF_INCLUDE) $(CLANG_SYS_INCLUDES)
+KHDR_INCLUDES := $(abspath $(OUTPUT)/../../usr/include)
+BPF_INCLUDE := -I$(SKEL_TMP_OUT)/.. -I$(LIBBPF_INCLUDE)
-I$(KHDR_INCLUDES) $(CLANG_SYS_INCLUDES)
 TOOLS_UAPI_INCLUDE := -I$(srctree)/tools/include/uapi

 ifneq ($(WERROR),0)


With this change verified, perf compiles successfully even without
explicitly specifying the cross-toolchain sysroot in the compile
command.

Therefore, before sending PATCH v4, I would appreciate your review and
any suggestions.

Thanks,
hupu

Hi Leo and Namhyung,

On Tue, Nov 18, 2025 at 3:18 PM hupu <hupu.gm@gmail.com> wrote:
>
> I then added KHDR_INCLUDES to BPF_INCLUDE, pointing it to the kernel’s
> self-contained header directory so that the build prefers headers
> provided by the kernel.
>
>
> diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> index 47c906b807ef..65c6e871988b 100644
> --- a/tools/perf/Makefile.perf
> +++ b/tools/perf/Makefile.perf
> @@ -1202,7 +1202,8 @@ endif
>
>  CLANG_OPTIONS = -Wall
>  CLANG_SYS_INCLUDES = $(call get_sys_includes,$(CLANG),$(CLANG_TARGET_ARCH))
> -BPF_INCLUDE := -I$(SKEL_TMP_OUT)/.. -I$(LIBBPF_INCLUDE) $(CLANG_SYS_INCLUDES)
> +KHDR_INCLUDES := $(abspath $(OUTPUT)/../../usr/include)
> +BPF_INCLUDE := -I$(SKEL_TMP_OUT)/.. -I$(LIBBPF_INCLUDE)
> -I$(KHDR_INCLUDES) $(CLANG_SYS_INCLUDES)
>  TOOLS_UAPI_INCLUDE := -I$(srctree)/tools/include/uapi
>
>  ifneq ($(WERROR),0)
>
>
> With this change verified, perf compiles successfully even without
> explicitly specifying the cross-toolchain sysroot in the compile
> command.
>

As an additional suggestion, I’d prefer to keep both the above patch
and the previously discussed PATCH v3, which would mean submitting two
PRs. From my perspective, allowing users to pass custom compilation
options via EXTRA_BPF_FLAGS is more flexible than only configuring
headers, so I’d like to hear your thoughts.

Thanks,
hupu

RESEND

On Tue, Nov 18, 2025 at 3:28 PM hupu <hupu.gm@gmail.com> wrote:
>
> Hi Leo and Namhyung,
>
> On Tue, Nov 18, 2025 at 3:18 PM hupu <hupu.gm@gmail.com> wrote:
> >
> > I then added KHDR_INCLUDES to BPF_INCLUDE, pointing it to the kernel’s
> > self-contained header directory so that the build prefers headers
> > provided by the kernel.
> >
> >
> > diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> > index 47c906b807ef..65c6e871988b 100644
> > --- a/tools/perf/Makefile.perf
> > +++ b/tools/perf/Makefile.perf
> > @@ -1202,7 +1202,8 @@ endif
> >
> >  CLANG_OPTIONS = -Wall
> >  CLANG_SYS_INCLUDES = $(call get_sys_includes,$(CLANG),$(CLANG_TARGET_ARCH))
> > -BPF_INCLUDE := -I$(SKEL_TMP_OUT)/.. -I$(LIBBPF_INCLUDE) $(CLANG_SYS_INCLUDES)
> > +KHDR_INCLUDES := $(abspath $(OUTPUT)/../../usr/include)
> > +BPF_INCLUDE := -I$(SKEL_TMP_OUT)/.. -I$(LIBBPF_INCLUDE)
> > -I$(KHDR_INCLUDES) $(CLANG_SYS_INCLUDES)
> >  TOOLS_UAPI_INCLUDE := -I$(srctree)/tools/include/uapi
> >
> >  ifneq ($(WERROR),0)
> >
> >
> > With this change verified, perf compiles successfully even without
> > explicitly specifying the cross-toolchain sysroot in the compile
> > command.
> >
>
> As an additional suggestion, I’d prefer to keep both the above patch
> and the previously discussed PATCH v3, which would mean submitting two
> PRs. From my perspective, allowing users to pass custom compilation
> options via EXTRA_BPF_FLAGS is more flexible than only configuring
> headers, so I’d like to hear your thoughts.
>
> Thanks,
> hupu

Hello,

On Wed, Nov 19, 2025 at 05:43:41PM +0800, hupu wrote:
> RESEND
> 
> On Tue, Nov 18, 2025 at 3:28 PM hupu <hupu.gm@gmail.com> wrote:
> >
> > Hi Leo and Namhyung,
> >
> > On Tue, Nov 18, 2025 at 3:18 PM hupu <hupu.gm@gmail.com> wrote:
> > >
> > > I then added KHDR_INCLUDES to BPF_INCLUDE, pointing it to the kernel’s
> > > self-contained header directory so that the build prefers headers
> > > provided by the kernel.
> > >
> > >
> > > diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> > > index 47c906b807ef..65c6e871988b 100644
> > > --- a/tools/perf/Makefile.perf
> > > +++ b/tools/perf/Makefile.perf
> > > @@ -1202,7 +1202,8 @@ endif
> > >
> > >  CLANG_OPTIONS = -Wall
> > >  CLANG_SYS_INCLUDES = $(call get_sys_includes,$(CLANG),$(CLANG_TARGET_ARCH))
> > > -BPF_INCLUDE := -I$(SKEL_TMP_OUT)/.. -I$(LIBBPF_INCLUDE) $(CLANG_SYS_INCLUDES)
> > > +KHDR_INCLUDES := $(abspath $(OUTPUT)/../../usr/include)
> > > +BPF_INCLUDE := -I$(SKEL_TMP_OUT)/.. -I$(LIBBPF_INCLUDE)
> > > -I$(KHDR_INCLUDES) $(CLANG_SYS_INCLUDES)

I think your patch was wrapped around.

> > >  TOOLS_UAPI_INCLUDE := -I$(srctree)/tools/include/uapi
> > >
> > >  ifneq ($(WERROR),0)
> > >
> > >
> > > With this change verified, perf compiles successfully even without
> > > explicitly specifying the cross-toolchain sysroot in the compile
> > > command.

I'm not familiar with the usr directory in the kernel source.  Will it
contain some generated headers?

> > >
> >
> > As an additional suggestion, I’d prefer to keep both the above patch
> > and the previously discussed PATCH v3, which would mean submitting two
> > PRs. From my perspective, allowing users to pass custom compilation
> > options via EXTRA_BPF_FLAGS is more flexible than only configuring
> > headers, so I’d like to hear your thoughts.

Yep, I'm ok with the extra flag variable.

Thanks,
Namhyung

Hi Namhyung,
Thank you very much for your reply.

On Fri, Nov 21, 2025 at 3:23 AM Namhyung Kim <namhyung@kernel.org> wrote:
>
> Hello,
>
> On Wed, Nov 19, 2025 at 05:43:41PM +0800, hupu wrote:
> > RESEND
> >
> > On Tue, Nov 18, 2025 at 3:28 PM hupu <hupu.gm@gmail.com> wrote:
> > >
> > > Hi Leo and Namhyung,
> > >
> > > On Tue, Nov 18, 2025 at 3:18 PM hupu <hupu.gm@gmail.com> wrote:
> > > >
> > > > I then added KHDR_INCLUDES to BPF_INCLUDE, pointing it to the kernel’s
> > > > self-contained header directory so that the build prefers headers
> > > > provided by the kernel.
> > > >
> > > >
> > > > diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> > > > index 47c906b807ef..65c6e871988b 100644
> > > > --- a/tools/perf/Makefile.perf
> > > > +++ b/tools/perf/Makefile.perf
> > > > @@ -1202,7 +1202,8 @@ endif
> > > >
> > > >  CLANG_OPTIONS = -Wall
> > > >  CLANG_SYS_INCLUDES = $(call get_sys_includes,$(CLANG),$(CLANG_TARGET_ARCH))
> > > > -BPF_INCLUDE := -I$(SKEL_TMP_OUT)/.. -I$(LIBBPF_INCLUDE) $(CLANG_SYS_INCLUDES)
> > > > +KHDR_INCLUDES := $(abspath $(OUTPUT)/../../usr/include)
> > > > +BPF_INCLUDE := -I$(SKEL_TMP_OUT)/.. -I$(LIBBPF_INCLUDE)
> > > > -I$(KHDR_INCLUDES) $(CLANG_SYS_INCLUDES)
>
> I think your patch was wrapped around.
>

Oh, yes — that line was automatically wrapped by the mail system
because it exceeded 80 characters.
I’ve slightly adjusted it so that it can be displayed correctly in
email clients, as shown below:

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 47c906b807ef..eaccaae87e3c 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -1202,7 +1202,9 @@ endif

 CLANG_OPTIONS = -Wall
 CLANG_SYS_INCLUDES = $(call get_sys_includes,$(CLANG),$(CLANG_TARGET_ARCH))
-BPF_INCLUDE := -I$(SKEL_TMP_OUT)/.. -I$(LIBBPF_INCLUDE) $(CLANG_SYS_INCLUDES)
+KHDR_INCLUDES := $(abspath $(OUTPUT)/../../usr/include)
+BPF_INCLUDE := -I$(SKEL_TMP_OUT)/.. -I$(LIBBPF_INCLUDE) \
+               -I$(KHDR_INCLUDES) $(CLANG_SYS_INCLUDES)
 TOOLS_UAPI_INCLUDE := -I$(srctree)/tools/include/uapi

 ifneq ($(WERROR),0)


> > > >  TOOLS_UAPI_INCLUDE := -I$(srctree)/tools/include/uapi
> > > >
> > > >  ifneq ($(WERROR),0)
> > > >
> > > >
> > > > With this change verified, perf compiles successfully even without
> > > > explicitly specifying the cross-toolchain sysroot in the compile
> > > > command.
>
> I'm not familiar with the usr directory in the kernel source.  Will it
> contain some generated headers?
>

Yes, the headers in KHDR_INCLUDES are directly copied from the kernel
source tree (sometimes with very minor modifications). They are
exactly the headers required during perf compilation.

> > > >
> > >
> > > As an additional suggestion, I’d prefer to keep both the above patch
> > > and the previously discussed PATCH v3, which would mean submitting two
> > > PRs. From my perspective, allowing users to pass custom compilation
> > > options via EXTRA_BPF_FLAGS is more flexible than only configuring
> > > headers, so I’d like to hear your thoughts.
>
> Yep, I'm ok with the extra flag variable.
>
> Thanks,
> Namhyung
>

Leo, what are your thoughts on this? I’d appreciate hearing your suggestions.

Thanks,
hupu

Hi Leo and Namhyung,

On Fri, Nov 21, 2025 at 6:17 PM hupu <hupu.gm@gmail.com> wrote:
> > > >
> > > > As an additional suggestion, I’d prefer to keep both the above patch
> > > > and the previously discussed PATCH v3, which would mean submitting two
> > > > PRs. From my perspective, allowing users to pass custom compilation
> > > > options via EXTRA_BPF_FLAGS is more flexible than only configuring
> > > > headers, so I’d like to hear your thoughts.
> >
> > Yep, I'm ok with the extra flag variable.
> >
> > Thanks,
> > Namhyung
> >
>
> Leo, what are your thoughts on this? I’d appreciate hearing your suggestions.
>


Based on our previous discussion, I have prepared two PATCHes. In this
email, let’s continue our discussion on whether we should use the
extra flag variable. For the topic of using the kernel’s native
self-contained headers, please refer to my other email at the link
below.


https://lore.kernel.org/all/20251124072310.3592-1-hupu.gm@gmail.com/


Thanks,
hupu

When cross-compiling perf with BPF enabled, Clang is invoked during the
build. Some cross-compilation environments require additional compiler
options, such as `--sysroot` or custom include paths.

This patch introduces a new Make variable, `EXTRA_BPF_FLAGS`. During BPF
skeleton builds, it appends user-provided options to `CLANG_OPTIONS`,
allowing extra Clang flags to be set without modifying Makefile.perf
directly.

Example usage:
    make perf ARCH="arm64" EXTRA_BPF_FLAGS="--sysroot=..."

Change history:
  v3:
    - Move the variable description comment to the top of Makefile.perf
    - Update commit message
  v2:
    - Rename EXTRA_CLANG_FLAGS to EXTRA_BPF_FLAGS
    - Update commit message
  v1:
    - Introduce EXTRA_CLANG_FLAGS to allow passing extra Clang options

Signed-off-by: hupu <hupu.gm@gmail.com>
---
 tools/perf/Makefile.perf | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 47c906b807ef..c1a66cf3d1a7 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -35,6 +35,9 @@ include ../scripts/utilities.mak
 #
 # Define EXTRA_CFLAGS=-m64 or EXTRA_CFLAGS=-m32 as appropriate for cross-builds.
 #
+# Define EXTRA_BPF_FLAGS="--sysroot=<path>" or other custom include paths for
+# cross-compiling BPF skeletons
+#
 # Define EXCLUDE_EXTLIBS=-lmylib to exclude libmylib from the auto-generated
 # EXTLIBS.
 #
@@ -1249,6 +1252,8 @@ else
 	$(Q)cp "$(VMLINUX_H)" $@
 endif
 
+CLANG_OPTIONS += $(EXTRA_BPF_FLAGS)
+
 $(SKEL_TMP_OUT)/%.bpf.o: $(OUTPUT)PERF-VERSION-FILE util/bpf_skel/perf_version.h | $(SKEL_TMP_OUT)
 $(SKEL_TMP_OUT)/%.bpf.o: util/bpf_skel/%.bpf.c $(LIBBPF) $(SKEL_OUT)/vmlinux.h
 	$(QUIET_CLANG)$(CLANG) -g -O2 -fno-stack-protector --target=bpf \
-- 
2.43.0

Hello,

On Mon, Nov 24, 2025 at 03:34:45PM +0800, hupu wrote:
> When cross-compiling perf with BPF enabled, Clang is invoked during the
> build. Some cross-compilation environments require additional compiler
> options, such as `--sysroot` or custom include paths.
> 
> This patch introduces a new Make variable, `EXTRA_BPF_FLAGS`. During BPF
> skeleton builds, it appends user-provided options to `CLANG_OPTIONS`,
> allowing extra Clang flags to be set without modifying Makefile.perf
> directly.
> 
> Example usage:
>     make perf ARCH="arm64" EXTRA_BPF_FLAGS="--sysroot=..."
> 
> Change history:
>   v3:
>     - Move the variable description comment to the top of Makefile.perf
>     - Update commit message
>   v2:
>     - Rename EXTRA_CLANG_FLAGS to EXTRA_BPF_FLAGS
>     - Update commit message
>   v1:
>     - Introduce EXTRA_CLANG_FLAGS to allow passing extra Clang options
> 
> Signed-off-by: hupu <hupu.gm@gmail.com>
> ---
>  tools/perf/Makefile.perf | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> index 47c906b807ef..c1a66cf3d1a7 100644
> --- a/tools/perf/Makefile.perf
> +++ b/tools/perf/Makefile.perf
> @@ -35,6 +35,9 @@ include ../scripts/utilities.mak
>  #
>  # Define EXTRA_CFLAGS=-m64 or EXTRA_CFLAGS=-m32 as appropriate for cross-builds.
>  #
> +# Define EXTRA_BPF_FLAGS="--sysroot=<path>" or other custom include paths for
> +# cross-compiling BPF skeletons
> +#
>  # Define EXCLUDE_EXTLIBS=-lmylib to exclude libmylib from the auto-generated
>  # EXTLIBS.
>  #
> @@ -1249,6 +1252,8 @@ else
>  	$(Q)cp "$(VMLINUX_H)" $@
>  endif
>  
> +CLANG_OPTIONS += $(EXTRA_BPF_FLAGS)

While it seems CLANG_OPTIONS is used only for BPF skeletons, I think
it's better to add it directly to the below lines instead of adding it
to CLANG_OPTIONS like following.

> +
>  $(SKEL_TMP_OUT)/%.bpf.o: $(OUTPUT)PERF-VERSION-FILE util/bpf_skel/perf_version.h | $(SKEL_TMP_OUT)
>  $(SKEL_TMP_OUT)/%.bpf.o: util/bpf_skel/%.bpf.c $(LIBBPF) $(SKEL_OUT)/vmlinux.h
>  	$(QUIET_CLANG)$(CLANG) -g -O2 -fno-stack-protector --target=bpf \

	  $(CLANG_OPTIONS) $(EXTRA_BPF_FLAGS) $(BPF_INCLUDE) $(TOOLS_UAPI_INCLUDE) \

Thanks,
Namhyung

Hi Namhyung,
Thank you very much for your valuable suggestion.

On Tue, Nov 25, 2025 at 4:13 PM Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > +CLANG_OPTIONS += $(EXTRA_BPF_FLAGS)
>
> While it seems CLANG_OPTIONS is used only for BPF skeletons, I think
> it's better to add it directly to the below lines instead of adding it
> to CLANG_OPTIONS like following.
>
> > +
> >  $(SKEL_TMP_OUT)/%.bpf.o: $(OUTPUT)PERF-VERSION-FILE util/bpf_skel/perf_version.h | $(SKEL_TMP_OUT)
> >  $(SKEL_TMP_OUT)/%.bpf.o: util/bpf_skel/%.bpf.c $(LIBBPF) $(SKEL_OUT)/vmlinux.h
> >       $(QUIET_CLANG)$(CLANG) -g -O2 -fno-stack-protector --target=bpf \
>
>           $(CLANG_OPTIONS) $(EXTRA_BPF_FLAGS) $(BPF_INCLUDE) $(TOOLS_UAPI_INCLUDE) \
>

I agree that this approach makes the logic clearer, and I will update
the v4 patch to follow your recommendation.

Thanks again for your review and guidance.

Thanks，
hupu

When cross-compiling perf with BPF enabled, Clang is invoked during the
build. Some cross-compilation environments require additional compiler
options, such as `--sysroot` or custom include paths.

This patch introduces a new Make variable, `EXTRA_BPF_FLAGS`. During BPF
skeleton builds, it appends user-provided options to `CLANG_OPTIONS`,
allowing extra Clang flags to be set without modifying Makefile.perf
directly.

Example usage:
    make perf ARCH="arm64" EXTRA_BPF_FLAGS="--sysroot=..."

Change history:
  v4:
    - Apply EXTRA_BPF_FLAGS directly to BPF skeleton build command
      instead of modifying CLANG_OPTIONS
  v3:
    - Move the variable description comment to the top of Makefile.perf
    - Update commit message
  v2:
    - Rename EXTRA_CLANG_FLAGS to EXTRA_BPF_FLAGS
    - Update commit message
  v1:
    - Introduce EXTRA_CLANG_FLAGS to allow passing extra Clang options

Signed-off-by: hupu <hupu.gm@gmail.com>
---
 tools/perf/Makefile.perf | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 47c906b807ef..e1cf6accaa4c 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -35,6 +35,9 @@ include ../scripts/utilities.mak
 #
 # Define EXTRA_CFLAGS=-m64 or EXTRA_CFLAGS=-m32 as appropriate for
cross-builds.
 #
+# Define EXTRA_BPF_FLAGS="--sysroot=<path>" or other custom include paths for
+# cross-compiling BPF skeletons
+#
 # Define EXCLUDE_EXTLIBS=-lmylib to exclude libmylib from the auto-generated
 # EXTLIBS.
 #
@@ -1252,7 +1255,7 @@ endif
 $(SKEL_TMP_OUT)/%.bpf.o: $(OUTPUT)PERF-VERSION-FILE
util/bpf_skel/perf_version.h | $(SKEL_TMP_OUT)
 $(SKEL_TMP_OUT)/%.bpf.o: util/bpf_skel/%.bpf.c $(LIBBPF) $(SKEL_OUT)/vmlinux.h
  $(QUIET_CLANG)$(CLANG) -g -O2 -fno-stack-protector --target=bpf \
-   $(CLANG_OPTIONS) $(BPF_INCLUDE) $(TOOLS_UAPI_INCLUDE) \
+   $(CLANG_OPTIONS) $(EXTRA_BPF_FLAGS) $(BPF_INCLUDE) $(TOOLS_UAPI_INCLUDE) \
    -include $(OUTPUT)PERF-VERSION-FILE -include util/bpf_skel/perf_version.h \
    -c $(filter util/bpf_skel/%.bpf.c,$^) -o $@

-- 
2.43.0

On Tue, Nov 25, 2025 at 09:07:26PM +0800, hupu wrote:

[...]

> --- a/tools/perf/Makefile.perf
> +++ b/tools/perf/Makefile.perf
> @@ -35,6 +35,9 @@ include ../scripts/utilities.mak
>  #
>  # Define EXTRA_CFLAGS=-m64 or EXTRA_CFLAGS=-m32 as appropriate for
> cross-builds.
>  #
> +# Define EXTRA_BPF_FLAGS="--sysroot=<path>" or other custom include paths for
> +# cross-compiling BPF skeletons
> +#
>  # Define EXCLUDE_EXTLIBS=-lmylib to exclude libmylib from the auto-generated
>  # EXTLIBS.
>  #
> @@ -1252,7 +1255,7 @@ endif
>  $(SKEL_TMP_OUT)/%.bpf.o: $(OUTPUT)PERF-VERSION-FILE
> util/bpf_skel/perf_version.h | $(SKEL_TMP_OUT)
>  $(SKEL_TMP_OUT)/%.bpf.o: util/bpf_skel/%.bpf.c $(LIBBPF) $(SKEL_OUT)/vmlinux.h
>   $(QUIET_CLANG)$(CLANG) -g -O2 -fno-stack-protector --target=bpf \
> -   $(CLANG_OPTIONS) $(BPF_INCLUDE) $(TOOLS_UAPI_INCLUDE) \
> +   $(CLANG_OPTIONS) $(EXTRA_BPF_FLAGS) $(BPF_INCLUDE) $(TOOLS_UAPI_INCLUDE) \

I am concerned for this change.

How can you only build eBPF skel program with "--sysroot" but not
applying the same build env on perf binary and associated libs (libperf,
bpftool, etc) ?

For a convinced solution, I'd expect we can apply PKG_CONFIG_SYSROOT_DIR
for both normal perf build and eBPF skel build.  More important, please
provide steps for how to build perf with a SDK.

Thanks,
Leo

Hi Leo,
Thank you for your reply.

On Wed, Nov 26, 2025 at 12:10 AM Leo Yan <leo.yan@arm.com> wrote:
>
> On Tue, Nov 25, 2025 at 09:07:26PM +0800, hupu wrote:
>
> [...]
>
> > --- a/tools/perf/Makefile.perf
> > +++ b/tools/perf/Makefile.perf
> > @@ -35,6 +35,9 @@ include ../scripts/utilities.mak
> >  #
> >  # Define EXTRA_CFLAGS=-m64 or EXTRA_CFLAGS=-m32 as appropriate for
> > cross-builds.
> >  #
> > +# Define EXTRA_BPF_FLAGS="--sysroot=<path>" or other custom include paths for
> > +# cross-compiling BPF skeletons
> > +#
> >  # Define EXCLUDE_EXTLIBS=-lmylib to exclude libmylib from the auto-generated
> >  # EXTLIBS.
> >  #
> > @@ -1252,7 +1255,7 @@ endif
> >  $(SKEL_TMP_OUT)/%.bpf.o: $(OUTPUT)PERF-VERSION-FILE
> > util/bpf_skel/perf_version.h | $(SKEL_TMP_OUT)
> >  $(SKEL_TMP_OUT)/%.bpf.o: util/bpf_skel/%.bpf.c $(LIBBPF) $(SKEL_OUT)/vmlinux.h
> >   $(QUIET_CLANG)$(CLANG) -g -O2 -fno-stack-protector --target=bpf \
> > -   $(CLANG_OPTIONS) $(BPF_INCLUDE) $(TOOLS_UAPI_INCLUDE) \
> > +   $(CLANG_OPTIONS) $(EXTRA_BPF_FLAGS) $(BPF_INCLUDE) $(TOOLS_UAPI_INCLUDE) \
>
> I am concerned for this change.
>
> How can you only build eBPF skel program with "--sysroot" but not
> applying the same build env on perf binary and associated libs (libperf,
> bpftool, etc) ?
>
> For a convinced solution, I'd expect we can apply PKG_CONFIG_SYSROOT_DIR
> for both normal perf build and eBPF skel build.  More important, please
>

I understand your concern, and I will explain it with reference to the
current source code.


The eBPF skeleton is compiled via clang --target=bpf, and its header
file search paths mainly come from BPF_INCLUDE and TOOLS_UAPI_INCLUDE.
It also uses '-idirafter' to include the host’s /usr/local/include and
/usr/include directories in the search path. This process is not
directly coupled with cross-compilation managed via pkg-config, which
means PKG_CONFIG_SYSROOT_DIR does not affect how the skeleton resolves
its headers.

1252 $(SKEL_TMP_OUT)/%.bpf.o: $(OUTPUT)PERF-VERSION-FILE
util/bpf_skel/perf_version.h | $(SKEL_TMP_OUT)
1253 $(SKEL_TMP_OUT)/%.bpf.o: util/bpf_skel/%.bpf.c $(LIBBPF)
$(SKEL_OUT)/vmlinux.h
1254         $(QUIET_CLANG)$(CLANG) -g -O2 -fno-stack-protector --target=bpf \
1255           $(CLANG_OPTIONS) $(BPF_INCLUDE) $(TOOLS_UAPI_INCLUDE) \
1256           -include $(OUTPUT)PERF-VERSION-FILE -include
util/bpf_skel/perf_version.h \
1257           -c $(filter util/bpf_skel/%.bpf.c,$^) -o $@


I added some debugging output to inspect the contents of BPF_INCLUDE:

BPF_INCLUDE:
-I/home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/..
-I/home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/include
-idirafter /usr/lib/llvm-18/lib/clang/18/include
-idirafter /usr/local/include
-idirafter /usr/include


The perf binary and its associated libraries (such as libperf) are
built with the cross toolchain. Their dependency headers and library
paths are determined by CFLAGS/LDFLAGS and resolved via pkg-config. In
this case, PKG_CONFIG_SYSROOT_DIR is indeed the correct control point.

802 $(OUTPUT)perf: $(PERFLIBS) $(PERF_IN)
803         $(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) \
804                 $(PERF_IN) $(LIBS) -o $@

971 $(LIBPERF): FORCE | $(LIBPERF_OUTPUT)
972         $(Q)$(MAKE) -C $(LIBPERF_DIR) O=$(LIBPERF_OUTPUT) \
973                 DESTDIR=$(LIBPERF_DESTDIR) prefix= subdir= \
974                 $@ install_headers


From the current build logic, there is no strict requirement for the
skeleton and the perf binary to use exactly the same headers, because
we cannot guarantee that the headers in the host’s /usr/local/include
and /usr/include are fully consistent with the kernel source.

If the goal is to enforce header consistency, my other proposed patch
— “perf build: Use self-contained headers from kernel source when
compiling” — explicitly ensures that the skeleton uses UAPI headers
from the kernel source tree, thus aligning the skeleton’s headers with
those used by the perf binary.

Finally, introducing EXTRA_BPF_FLAGS offers a controlled, optional
extension point for the skeleton build, rather than solely passing
--sysroot. This allows users to add additional options such as -I or
-D to address specific include resolution needs in certain
environments. It is more flexible than hardcoding paths, and does not
modify the existing pkg-config managed search paths used for
user-space builds.


> for both normal perf build and eBPF skel build.  More important, please
> provide steps for how to build perf with a SDK.
>

(I apologize in advance — I may paste some build log output below.
This could make the email appear somewhat cluttered, and may also
cause line wrapping or truncation in some mail clients.)

If EXTRA_BPF_FLAGS is not specified during the perf build (example
command shown below), the compilation will fail:
make perf ARCH=arm64 CROSS_COMPILE=aarch64-dumpstack-linux-gnu-
LDFLAGS="-L/home/hupu/work/tools/x-tools/aarch64-dumpstack-linux-gnu/bin/../aarch64-dumpstack-linux-gnu/sysroot/usr/lib/aarch64-linux-gnu
-L/home/hupu/work/tools/x-tools/aarch64-dumpstack-linux-gnu/bin/../aarch64-dumpstack-linux-gnu/sysroot/usr/lib
-static"  O=/home/hupu/work/code/explore/output/build-mainline -j8


The full build failure log is as follows:

21:38:16 (00:00:00) - INFO  : Starting build perf tools for arm64 ...
21:38:16 (00:00:00) - INFO  : make perf ARCH=arm64
CROSS_COMPILE=aarch64-dumpstack-linux-gnu-
LDFLAGS="-L/home/hupu/work/tools/x-tools/aarch64-dumpstack-linux-gnu/bin/../aarch64-dumpstack-linux-gnu/sysroot/usr/lib/aarch64-linux-gnu
-L/home/hupu/work/tools/x-tools/aarch64-dumpstack-linux-gnu/bin/../aarch64-dumpstack-linux-gnu/sysroot/usr/lib
-static"  O=/home/hupu/work/code/explore/output/build-mainline -j8
  BUILD:   Doing 'make -j4' parallel build
Warning: Kernel ABI header differences:
  diff -u tools/arch/arm64/include/asm/cputype.h
arch/arm64/include/asm/cputype.h
  diff -u tools/perf/trace/beauty/include/uapi/linux/mount.h
include/uapi/linux/mount.h
Makefile.config:590: No elfutils/debuginfod.h found, no debuginfo
server support, please install
libdebuginfod-dev/elfutils-debuginfod-client-devel or equivalent
Makefile.config:633: No sys/sdt.h found, no SDT events are defined,
please install systemtap-sdt-devel or systemtap-sdt-dev
Makefile.config:881: No 'Python.h' was found: disables Python support
- please install python-devel/python-dev
Makefile.config:989: No libllvm 13+ found, slower source file
resolution, please install llvm-devel/llvm-dev
Makefile.config:1099: No libbabeltrace found, disables 'perf data' CTF
format support, please install
libbabeltrace-dev[el]/libbabeltrace-ctf-dev
Makefile.config:1142: No alternatives command found, you need to set
JDIR= to point to the root of your Java directory
Makefile.config:1173: libpfm4 not found, disables libpfm4 support.
Please install libpfm-devel or libpfm4-dev

Auto-detecting system features:
...                                   libdw: [ on  ]
...                                   glibc: [ on  ]
...                                  libelf: [ on  ]
...                                 libnuma: [ on  ]
...                  numa_num_possible_cpus: [ on  ]
...                               libpython: [ OFF ]
...                             libcapstone: [ on  ]
...                               llvm-perf: [ OFF ]
...                                    zlib: [ on  ]
...                                    lzma: [ on  ]
...                               get_cpuid: [ OFF ]
...                                     bpf: [ on  ]
...                                  libaio: [ on  ]
...                                 libzstd: [ on  ]

  GEN     /home/hupu/work/code/explore/output/build-mainline/tools/perf/common-cmds.h
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/dlfilters/dlfilter-test-api-v0.o
  GEN     /home/hupu/work/code/explore/output/build-mainline/tools/perf/arch/arm64/include/generated/asm/sysreg-defs.h
  PERF_VERSION = 6.18.rc7.g30f09200cc4a
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/dlfilters/dlfilter-test-api-v2.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/dlfilters/dlfilter-show-cycles.o
  MKDIR   /home/hupu/work/code/explore/output/build-mainline/tools/perf/libapi/fd/
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libapi/fd/array.o
  SYSHDR  /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/arch/arm64/include/generated/uapi/asm/unistd_64.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/include/perf/bpf_perf.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/include/perf/core.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/include/perf/cpumap.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/include/perf/threadmap.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/include/perf/evlist.h
  LD      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libapi/fd/libapi-in.o
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/include/perf/evsel.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/include/perf/event.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/include/perf/mmap.h
  MKDIR   /home/hupu/work/code/explore/output/build-mainline/tools/perf/libapi/fs/
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/include/internal/cpumap.h
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libapi/fs/fs.o
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/include/internal/evlist.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libsubcmd/include/subcmd/exec-cmd.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/include/internal/evsel.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libsubcmd/include/subcmd/help.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/include/internal/lib.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/include/internal/mmap.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libsubcmd/include/subcmd/pager.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/include/internal/rc_check.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libsubcmd/include/subcmd/parse-options.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/include/internal/threadmap.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/include/internal/xyarray.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libsubcmd/include/subcmd/run-command.h
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/core.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libsubcmd/exec-cmd.o
  INSTALL libsubcmd_headers
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libapi/include/api/cpu.h
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libapi/cpu.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/cpumap.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libapi/debug.o
  MKDIR   /home/hupu/work/code/explore/output/build-mainline/tools/perf/libapi/fs/
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libapi/fs/tracing_path.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libsubcmd/help.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libapi/fs/cgroup.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libapi/str_error_r.o
  LD      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libapi/fs/libapi-in.o
  INSTALL libperf_headers
  LD      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libapi/libapi-in.o
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libapi/include/api/debug.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libapi/include/api/io.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libapi/include/api/io_dir.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libapi/include/api/fd/array.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libapi/include/api/fs/fs.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libapi/include/api/fs/tracing_path.h
  AR      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libapi/libapi.a
  INSTALL libapi_headers
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/threadmap.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libsymbol/kallsyms.o
  LD      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libsymbol/libsymbol-in.o
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libsymbol/include/symbol/kallsyms.h
  AR      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libsymbol/libsymbol.a
  INSTALL libsymbol_headers
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libsubcmd/pager.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/evsel.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libsubcmd/parse-options.o
  GEN     /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/bpf_helper_defs.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/include/bpf/bpf.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/include/bpf/libbpf.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/include/bpf/btf.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/include/bpf/libbpf_common.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/include/bpf/libbpf_legacy.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/include/bpf/bpf_helpers.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/include/bpf/bpf_tracing.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/include/bpf/bpf_endian.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/include/bpf/bpf_core_read.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/include/bpf/skel_internal.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/include/bpf/libbpf_version.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/include/bpf/usdt.bpf.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/include/bpf/bpf_helper_defs.h
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/staticobjs/libbpf.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/evlist.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libsubcmd/run-command.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libsubcmd/sigchain.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libsubcmd/subcmd-config.o
  LD      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libsubcmd/libsubcmd-in.o
  AR      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libsubcmd/libsubcmd.a
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/staticobjs/bpf.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/mmap.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/staticobjs/nlattr.o
  INSTALL libbpf_headers
  GEN     perf-archive
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/zalloc.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/staticobjs/btf.o
  GEN     perf-iostat
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/xyarray.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/lib.o
  LINK    /home/hupu/work/code/explore/output/build-mainline/tools/perf/dlfilters/dlfilter-test-api-v0.so
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/staticobjs/libbpf_utils.o
  LD      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/libperf-in.o
  AR      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libperf/libperf.a
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/staticobjs/netlink.o
  LINK    /home/hupu/work/code/explore/output/build-mainline/tools/perf/dlfilters/dlfilter-test-api-v2.so
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/staticobjs/bpf_prog_linfo.o
  LINK    /home/hupu/work/code/explore/output/build-mainline/tools/perf/dlfilters/dlfilter-show-cycles.so
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/staticobjs/libbpf_probes.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/staticobjs/hashmap.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/staticobjs/btf_dump.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/staticobjs/ringbuf.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/staticobjs/strset.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/staticobjs/linker.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/staticobjs/gen_loader.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/staticobjs/relo_core.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/staticobjs/usdt.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/staticobjs/zip.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/staticobjs/elf.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/staticobjs/features.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/staticobjs/btf_iter.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/staticobjs/btf_relocate.o
  LD      /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/staticobjs/libbpf-in.o
  LINK    /home/hupu/work/code/explore/output/build-mainline/tools/perf/libbpf/libbpf.a

Auto-detecting system features:
...                         clang-bpf-co-re: [ on  ]
...                                    llvm: [ OFF ]
...                                  libcap: [ on  ]
...                                  libbfd: [ OFF ]

  MKDIR   /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/include/bpf
  MKDIR   /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/
  MKDIR   /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/include/bpf/hashmap.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/include/bpf/relo_core.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/include/bpf/libbpf_internal.h
  GEN     /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/bpf_helper_defs.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/include/bpf/bpf.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/include/bpf/libbpf.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/include/bpf/btf.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/include/bpf/libbpf_common.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/include/bpf/libbpf_legacy.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/include/bpf/bpf_helpers.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/include/bpf/bpf_tracing.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/include/bpf/bpf_endian.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/include/bpf/bpf_core_read.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/include/bpf/skel_internal.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/include/bpf/libbpf_version.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/include/bpf/usdt.bpf.h
  INSTALL /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/include/bpf/bpf_helper_defs.h
  INSTALL libbpf_headers
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/staticobjs/libbpf.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/staticobjs/bpf.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/staticobjs/nlattr.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/staticobjs/btf.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/staticobjs/libbpf_utils.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/staticobjs/netlink.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/staticobjs/bpf_prog_linfo.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/staticobjs/libbpf_probes.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/staticobjs/hashmap.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/staticobjs/btf_dump.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/staticobjs/ringbuf.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/staticobjs/strset.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/staticobjs/linker.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/staticobjs/gen_loader.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/staticobjs/relo_core.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/staticobjs/usdt.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/staticobjs/zip.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/staticobjs/elf.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/staticobjs/features.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/staticobjs/btf_iter.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/staticobjs/btf_relocate.o
  LD      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/staticobjs/libbpf-in.o
  LINK    /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/libbpf/libbpf.a
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/main.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/common.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/json_writer.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/gen.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/btf.o
  CC      /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/sign.o
  LINK    /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bootstrap/bpftool
/usr/bin/ld: skipping incompatible
/home/hupu/work/tools/x-tools/aarch64-dumpstack-linux-gnu/bin/../aarch64-dumpstack-linux-gnu/sysroot/usr/lib/aarch64-linux-gnu/libelf.a
when searching for -lelf
/usr/bin/ld: skipping incompatible
/home/hupu/work/tools/x-tools/aarch64-dumpstack-linux-gnu/bin/../aarch64-dumpstack-linux-gnu/sysroot/usr/lib/aarch64-linux-gnu/libelf.a
when searching for -lelf
/usr/bin/ld: skipping incompatible
/home/hupu/work/tools/x-tools/aarch64-dumpstack-linux-gnu/bin/../aarch64-dumpstack-linux-gnu/sysroot/usr/lib/aarch64-linux-gnu/libz.a
when searching for -lz
/usr/bin/ld: skipping incompatible
/home/hupu/work/tools/x-tools/aarch64-dumpstack-linux-gnu/bin/../aarch64-dumpstack-linux-gnu/sysroot/usr/lib/aarch64-linux-gnu/libz.a
when searching for -lz
/usr/bin/ld: skipping incompatible
/home/hupu/work/tools/x-tools/aarch64-dumpstack-linux-gnu/bin/../aarch64-dumpstack-linux-gnu/sysroot/usr/lib/aarch64-linux-gnu/libcrypto.a
when searching for -lcrypto
/usr/bin/ld: skipping incompatible
/home/hupu/work/tools/x-tools/aarch64-dumpstack-linux-gnu/bin/../aarch64-dumpstack-linux-gnu/sysroot/usr/lib/aarch64-linux-gnu/libcrypto.a
when searching for -lcrypto
/usr/bin/ld: skipping incompatible
/home/hupu/work/tools/x-tools/aarch64-dumpstack-linux-gnu/bin/../aarch64-dumpstack-linux-gnu/sysroot/usr/lib/aarch64-linux-gnu/libzstd.a
when searching for -lzstd
/usr/bin/ld: skipping incompatible
/home/hupu/work/tools/x-tools/aarch64-dumpstack-linux-gnu/bin/../aarch64-dumpstack-linux-gnu/sysroot/usr/lib/aarch64-linux-gnu/libzstd.a
when searching for -lzstd
/usr/bin/ld: skipping incompatible
/home/hupu/work/tools/x-tools/aarch64-dumpstack-linux-gnu/bin/../aarch64-dumpstack-linux-gnu/sysroot/usr/lib/libc.a
when searching for -lc
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-dso_dlfcn.o):
in function `dlfcn_globallookup':
(.text+0x1f): warning: Using 'dlopen' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-bio_addr.o):
in function `BIO_lookup_ex':
(.text+0xdbc): warning: Using 'getaddrinfo' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-bio_sock.o):
in function `BIO_gethostbyname':
(.text+0x85): warning: Using 'gethostbyname' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
  CLANG   /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bpf_prog_profiler.bpf.o
  CLANG   /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bperf_leader.bpf.o
  CLANG   /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bperf_follower.bpf.o
  CLANG   /home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bperf_cgroup.bpf.o
In file included from <built-in>:2:
In file included from ./util/bpf_skel/perf_version.h:6:
In file included from
/home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/../vmlinux.h:7:
In file included from
/home/hupu/work/code/explore/linux-mainline/tools/include/uapi/linux/perf_event.h:19:
/usr/include/linux/ioctl.h:5:10: fatal error: 'asm/ioctl.h' file not found
    5 | #include <asm/ioctl.h>
      |          ^~~~~~~~~~~~~
In file included from <built-in>:2:
In file included from ./util/bpf_skel/perf_version.h:6:
In file included from
/home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/../vmlinux.h:7:
In file included from
/home/hupu/work/code/explore/linux-mainline/tools/include/uapi/linux/perf_event.h:19:
/usr/include/linux/ioctl.h:5:10: fatal error: 'asm/ioctl.h' file not found
    5 | #include <asm/ioctl.h>
      |          ^~~~~~~~~~~~~
In file included from <built-in>:2:
In file included from ./util/bpf_skel/perf_version.h:6:
In file included from
/home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/../vmlinux.h:7:
In file included from
/home/hupu/work/code/explore/linux-mainline/tools/include/uapi/linux/perf_event.h:19:
/usr/include/linux/ioctl.h:5:10: fatal error: 'asm/ioctl.h' file not found
    5 | #include <asm/ioctl.h>
      |          ^~~~~~~~~~~~~
1 error generated.
In file included from <built-in>:2:
In file included from ./util/bpf_skel/perf_version.h:6:
In file included from
/home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/../vmlinux.h:7:
In file included from
/home/hupu/work/code/explore/linux-mainline/tools/include/uapi/linux/perf_event.h:19:
/usr/include/linux/ioctl.h:5:10: fatal error: 'asm/ioctl.h' file not found
    5 | #include <asm/ioctl.h>
      |          ^~~~~~~~~~~~~
1 error generated.
make[3]: *** [Makefile.perf:1254:
/home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bpf_prog_profiler.bpf.o]
Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: *** [Makefile.perf:1254:
/home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bperf_leader.bpf.o]
Error 1
1 error generated.
make[3]: *** [Makefile.perf:1254:
/home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bperf_follower.bpf.o]
Error 1
1 error generated.
make[3]: *** [Makefile.perf:1254:
/home/hupu/work/code/explore/output/build-mainline/tools/perf/util/bpf_skel/.tmp/bperf_cgroup.bpf.o]
Error 1
make[2]: *** [Makefile.perf:289: sub-make] Error 2
make[1]: *** [Makefile:76: all] Error 2
make: *** [Makefile:93: perf] Error 2




However, when applying the patch “perf build: Support passing extra
Clang options via EXTRA_BPF_FLAGS”, running the following command
successfully builds perf:

make perf ARCH=arm64 CROSS_COMPILE=aarch64-dumpstack-linux-gnu-
EXTRA_BPF_FLAGS="--sysroot=/home/hupu/work/tools/x-tools/aarch64-dumpstack-linux-gnu/bin/../aarch64-dumpstack-linux-gnu/sysroot"
LDFLAGS="-L/home/hupu/work/tools/x-tools/aarch64-dumpstack-linux-gnu/bin/../aarch64-dumpstack-linux-gnu/sysroot/usr/lib/aarch64-linux-gnu
-L/home/hupu/work/tools/x-tools/aarch64-dumpstack-linux-gnu/bin/../aarch64-dumpstack-linux-gnu/sysroot/usr/lib
-static"  O=/home/hupu/work/code/explore/output/build-mainline -j8



Similarly, when applying the patch “perf build: Use self-contained
headers from kernel source when compiling”, perf can also be
successfully built without specifying EXTRA_BPF_FLAGS:

make perf ARCH=arm64 CROSS_COMPILE=aarch64-dumpstack-linux-gnu-
LDFLAGS="-L/home/hupu/work/tools/x-tools/aarch64-dumpstack-linux-gnu/bin/../aarch64-dumpstack-linux-gnu/sysroot/usr/lib/aarch64-linux-gnu
-L/home/hupu/work/tools/x-tools/aarch64-dumpstack-linux-gnu/bin/../aarch64-dumpstack-linux-gnu/sysroot/usr/lib
-static"  O=/home/hupu/work/code/explore/output/build-mainline -j8



Therefore, both patches are valid approaches to successfully build perf.

Thanks,
hupu

On Wed, Nov 26, 2025 at 09:44:02PM +0800, hupu wrote:

Please don't spam on mailing list as you did. It is really bad practice.
You could find resources [1][2] to learn upstreaming and co-work on the
ML.

> The eBPF skeleton is compiled via clang --target=bpf, and its header
> file search paths mainly come from BPF_INCLUDE and TOOLS_UAPI_INCLUDE.
> It also uses '-idirafter' to include the host’s /usr/local/include and
> /usr/include directories in the search path. This process is not
> directly coupled with cross-compilation managed via pkg-config, which
> means PKG_CONFIG_SYSROOT_DIR does not affect how the skeleton resolves
> its headers.

Based on my limited knowledge, Clang does not provide its own headers.
It needs to rely on GCC's headers for compilation.  I do see the
Makefile does right thing for finding headers:

  Makefile.perf:1203: ***
  CLANG_SYS_INCLUDES=-idirafter /usr/lib/llvm-18/lib/clang/18/include
  -idirafter /usr/local/include
  -idirafter /usr/bin/../lib/gcc-cross/aarch64-linux-gnu/14/../../../../aarch64-linux-gnu/include
  -idirafter /usr/include/aarch64-linux-gnu
  -idirafter /usr/include

It is mess to add some random include paths and feed to clang.  We
already have provided a reliable way for building eBPF skelton program
- keep in mind, eBPF skeleton program is not any aarch64 cross
compilation, we just use clang for building bpf target.

My understanding is you don't have a sane setting up on your local
building env.

Thanks,
Leo

[1] https://static.linaro.org/connect/hkg18/presentations/hkg18-tr02.pdf
[2] https://static.linaro.org/connect/hkg18/presentations/hkg18-tr03.pdf

Hi Leo,
On Thu, Dec 11, 2025 at 6:40 PM Leo Yan <leo.yan@arm.com> wrote:
>
> On Wed, Nov 26, 2025 at 09:44:02PM +0800, hupu wrote:
>
> Please don't spam on mailing list as you did. It is really bad practice.
> You could find resources [1][2] to learn upstreaming and co-work on the
> ML.
>

I apologize for the inconvenience caused by my frequent emails. I only
hoped to bring this nearly two-month-long discussion to a conclusion
sooner.


> > The eBPF skeleton is compiled via clang --target=bpf, and its header
> > file search paths mainly come from BPF_INCLUDE and TOOLS_UAPI_INCLUDE.
> > It also uses '-idirafter' to include the host’s /usr/local/include and
> > /usr/include directories in the search path. This process is not
> > directly coupled with cross-compilation managed via pkg-config, which
> > means PKG_CONFIG_SYSROOT_DIR does not affect how the skeleton resolves
> > its headers.
>
> Based on my limited knowledge, Clang does not provide its own headers.
> It needs to rely on GCC's headers for compilation.  I do see the
> Makefile does right thing for finding headers:
>
>   Makefile.perf:1203: ***
>   CLANG_SYS_INCLUDES=-idirafter /usr/lib/llvm-18/lib/clang/18/include
>   -idirafter /usr/local/include
>   -idirafter /usr/bin/../lib/gcc-cross/aarch64-linux-gnu/14/../../../../aarch64-linux-gnu/include
>   -idirafter /usr/include/aarch64-linux-gnu
>   -idirafter /usr/include
>
> It is mess to add some random include paths and feed to clang.  We
> already have provided a reliable way for building eBPF skelton program
> - keep in mind, eBPF skeleton program is not any aarch64 cross
> compilation, we just use clang for building bpf target.
>
> My understanding is you don't have a sane setting up on your local
> building env.
>

Although I have explained my view in earlier emails, it seems the
discussion has returned to the initial state.

Indeed, as you mentioned in the early discussion, running the
following commands on the host to install certain packages can
successfully compile perf:
> $ sudo apt-get install gcc-aarch64-linux-gnu g++-aarch64-linux-gnu
> $ sudo apt-get install libc6-dev-aarch64-cross linux-libc-dev-aarch64-cross
> $ sudo apt-get install libc6-dev-arm64-cross linux-libc-dev-arm64-cross


However, I don’t think relying on the host build environment is the
best approach, for several reasons:

a) These commands install UAPI header files on the host, especially
`linux-libc-dev-aarch64-cross` and `linux-libc-dev-arm64-cross`. These
headers originate from the kernel source tree’s `include/uapi/` and
`arch/arm64/include/uapi/` directories, and their versions are tied to
the *HOST* kernel version. If the target kernel version is different,
mismatches may cause compilation errors or even runtime failures.

b) Even if `perf` can be compiled and run successfully now, there is
no guarantee that the kernel source headers will always match the
host-installed UAPI headers as the upstream kernel evolves.

c) In scenarios where the host acts as a general build server and
needs to build multiple target kernel versions, it is not possible to
ensure that the host UAPI headers are compatible with all target
versions.

d) As you pointed out, `CLANG_SYS_INCLUDES` does include host headers,
but it uses `-idirafter` instead of `-I`. This means the host headers
have lower priority. This change was introduced in commit a2af0f6b8ef7
("perf build: Add system include paths to BPF builds"); as noted in
the commit message, the preferred approach is to use kernel source
headers rather than potentially older ones from the system.


Based on this, I propose the following include order:
- Prefer kernel source headers
  [RFC] perf build: Use self-contained headers from kernel source when compiling
  https://lore.kernel.org/all/20251124072310.3592-1-hupu.gm@gmail.com/

- Allow users to specify header search paths matching the target
kernel version (eg. via `EXTRA_BPF_FLAGS`)
  [PATCH] perf build: Support passing extra Clang options via EXTRA_BPF_FLAGS
  https://lore.kernel.org/all/20251013080609.2070555-1-hupu.gm@gmail.com/

- Fall back to the host build environment only if necessary


In summary, while relying on the host build environment can fix the
current build issue, I believe it is not the optimal solution.

Anyway, regardless of the final decision, I will respect it. Before
concluding, I hope we can explore this further and involve more
maintainers in the discussion. As for your comment, "you don't have a
sane setting up on your local building env", I am not yet fully
convinced by this reason.

Lastly, I once again apologize for any disturbance caused by my
frequent emails, and I sincerely thank both you and Namhyung for your
involvement throughout this process. I also hope this discussion will
attract more attention so that additional maintainers can participate.

Thanks,
hupu

Hello,

On Fri, Dec 12, 2025 at 02:12:09PM +0800, hupu wrote:
> Hi Leo,
> On Thu, Dec 11, 2025 at 6:40 PM Leo Yan <leo.yan@arm.com> wrote:
> >
> > On Wed, Nov 26, 2025 at 09:44:02PM +0800, hupu wrote:
> >
> > Please don't spam on mailing list as you did. It is really bad practice.
> > You could find resources [1][2] to learn upstreaming and co-work on the
> > ML.
> >
> 
> I apologize for the inconvenience caused by my frequent emails. I only
> hoped to bring this nearly two-month-long discussion to a conclusion
> sooner.

Sorry for the delay.  But sometimes it takes time to get a consensus in
an open discussion.  And it's been in a merge window + travelling for
LPC 2025.  Please don't hurry up.

> 
> 
> > > The eBPF skeleton is compiled via clang --target=bpf, and its header
> > > file search paths mainly come from BPF_INCLUDE and TOOLS_UAPI_INCLUDE.
> > > It also uses '-idirafter' to include the host’s /usr/local/include and
> > > /usr/include directories in the search path. This process is not
> > > directly coupled with cross-compilation managed via pkg-config, which
> > > means PKG_CONFIG_SYSROOT_DIR does not affect how the skeleton resolves
> > > its headers.
> >
> > Based on my limited knowledge, Clang does not provide its own headers.
> > It needs to rely on GCC's headers for compilation.  I do see the
> > Makefile does right thing for finding headers:
> >
> >   Makefile.perf:1203: ***
> >   CLANG_SYS_INCLUDES=-idirafter /usr/lib/llvm-18/lib/clang/18/include
> >   -idirafter /usr/local/include
> >   -idirafter /usr/bin/../lib/gcc-cross/aarch64-linux-gnu/14/../../../../aarch64-linux-gnu/include
> >   -idirafter /usr/include/aarch64-linux-gnu
> >   -idirafter /usr/include
> >
> > It is mess to add some random include paths and feed to clang.  We
> > already have provided a reliable way for building eBPF skelton program
> > - keep in mind, eBPF skeleton program is not any aarch64 cross
> > compilation, we just use clang for building bpf target.
> >
> > My understanding is you don't have a sane setting up on your local
> > building env.
> >
> 
> Although I have explained my view in earlier emails, it seems the
> discussion has returned to the initial state.
> 
> Indeed, as you mentioned in the early discussion, running the
> following commands on the host to install certain packages can
> successfully compile perf:
> > $ sudo apt-get install gcc-aarch64-linux-gnu g++-aarch64-linux-gnu
> > $ sudo apt-get install libc6-dev-aarch64-cross linux-libc-dev-aarch64-cross
> > $ sudo apt-get install libc6-dev-arm64-cross linux-libc-dev-arm64-cross

At this point, I'm confused whether we are talking about general
cross-build or just BPF skeleton.  I agree with Leo that the skeleton
build should not require any host specific information rather than
vmlinux.h.

> 
> 
> However, I don’t think relying on the host build environment is the
> best approach, for several reasons:
> 
> a) These commands install UAPI header files on the host, especially
> `linux-libc-dev-aarch64-cross` and `linux-libc-dev-arm64-cross`. These
> headers originate from the kernel source tree’s `include/uapi/` and
> `arch/arm64/include/uapi/` directories, and their versions are tied to
> the *HOST* kernel version. If the target kernel version is different,
> mismatches may cause compilation errors or even runtime failures.
> 
> b) Even if `perf` can be compiled and run successfully now, there is
> no guarantee that the kernel source headers will always match the
> host-installed UAPI headers as the upstream kernel evolves.
> 
> c) In scenarios where the host acts as a general build server and
> needs to build multiple target kernel versions, it is not possible to
> ensure that the host UAPI headers are compatible with all target
> versions.
> 
> d) As you pointed out, `CLANG_SYS_INCLUDES` does include host headers,
> but it uses `-idirafter` instead of `-I`. This means the host headers
> have lower priority. This change was introduced in commit a2af0f6b8ef7
> ("perf build: Add system include paths to BPF builds"); as noted in
> the commit message, the preferred approach is to use kernel source
> headers rather than potentially older ones from the system.
> 
> 
> Based on this, I propose the following include order:
> - Prefer kernel source headers
>   [RFC] perf build: Use self-contained headers from kernel source when compiling
>   https://lore.kernel.org/all/20251124072310.3592-1-hupu.gm@gmail.com/
> 
> - Allow users to specify header search paths matching the target
> kernel version (eg. via `EXTRA_BPF_FLAGS`)
>   [PATCH] perf build: Support passing extra Clang options via EXTRA_BPF_FLAGS
>   https://lore.kernel.org/all/20251013080609.2070555-1-hupu.gm@gmail.com/

I'm ok with this part - not only to pass header search paths, it can do
anything user wants to add to the compiler.  You may want to send it out
in a separate thread with all comments addressed.

> 
> - Fall back to the host build environment only if necessary
> 
> 
> In summary, while relying on the host build environment can fix the
> current build issue, I believe it is not the optimal solution.
> 
> Anyway, regardless of the final decision, I will respect it. Before
> concluding, I hope we can explore this further and involve more
> maintainers in the discussion. As for your comment, "you don't have a
> sane setting up on your local building env", I am not yet fully
> convinced by this reason.
> 
> Lastly, I once again apologize for any disturbance caused by my
> frequent emails, and I sincerely thank both you and Namhyung for your
> involvement throughout this process. I also hope this discussion will
> attract more attention so that additional maintainers can participate.

Thanks for your understanding,
Namhyung

Hi Namhyung,
Thank you very much for your reply.

On Tue, Dec 16, 2025 at 1:58 PM Namhyung Kim <namhyung@kernel.org> wrote:
>
> > Indeed, as you mentioned in the early discussion, running the
> > following commands on the host to install certain packages can
> > successfully compile perf:
> > > $ sudo apt-get install gcc-aarch64-linux-gnu g++-aarch64-linux-gnu
> > > $ sudo apt-get install libc6-dev-aarch64-cross linux-libc-dev-aarch64-cross
> > > $ sudo apt-get install libc6-dev-arm64-cross linux-libc-dev-arm64-cross
>
> At this point, I'm confused whether we are talking about general
> cross-build or just BPF skeleton.  I agree with Leo that the skeleton
> build should not require any host specific information rather than
> vmlinux.h.
>

I agree with this point. This is also what I was trying to express
earlier: although installing some additional packages on the host can
indeed make perf build successfully, in my view this approach is not
an ideal solution.

> >
> >
> > However, I don’t think relying on the host build environment is the
> > best approach, for several reasons:
> >
> > a) These commands install UAPI header files on the host, especially
> > `linux-libc-dev-aarch64-cross` and `linux-libc-dev-arm64-cross`. These
> > headers originate from the kernel source tree’s `include/uapi/` and
> > `arch/arm64/include/uapi/` directories, and their versions are tied to
> > the *HOST* kernel version. If the target kernel version is different,
> > mismatches may cause compilation errors or even runtime failures.
> >
> > b) Even if `perf` can be compiled and run successfully now, there is
> > no guarantee that the kernel source headers will always match the
> > host-installed UAPI headers as the upstream kernel evolves.
> >
> > c) In scenarios where the host acts as a general build server and
> > needs to build multiple target kernel versions, it is not possible to
> > ensure that the host UAPI headers are compatible with all target
> > versions.
> >
> > d) As you pointed out, `CLANG_SYS_INCLUDES` does include host headers,
> > but it uses `-idirafter` instead of `-I`. This means the host headers
> > have lower priority. This change was introduced in commit a2af0f6b8ef7
> > ("perf build: Add system include paths to BPF builds"); as noted in
> > the commit message, the preferred approach is to use kernel source
> > headers rather than potentially older ones from the system.
> >
> >
> > Based on this, I propose the following include order:
> > - Prefer kernel source headers
> >   [RFC] perf build: Use self-contained headers from kernel source when compiling
> >   https://lore.kernel.org/all/20251124072310.3592-1-hupu.gm@gmail.com/
> >
> > - Allow users to specify header search paths matching the target
> > kernel version (eg. via `EXTRA_BPF_FLAGS`)
> >   [PATCH] perf build: Support passing extra Clang options via EXTRA_BPF_FLAGS
> >   https://lore.kernel.org/all/20251013080609.2070555-1-hupu.gm@gmail.com/
>
> I'm ok with this part - not only to pass header search paths, it can do
> anything user wants to add to the compiler.  You may want to send it out
> in a separate thread with all comments addressed.
>

Thank you very much for this suggestion. I understand that you would
prefer to continue the discussion in a new, separate email thread, and
I am happy to do so.

Before proceeding, I would like to clarify your intention to make sure
I understand it correctly and avoid any misunderstanding. Since the
discussion above involves two patches with different functionalities,
I would like to confirm whether you would prefer me to combine these
two patches into a single one, or to discuss and resend both patches
together in a new separate email thread.


Thanks again for your time and guidance.
hupu

Hello,

On Tue, Dec 16, 2025 at 08:29:04PM +0800, hupu wrote:
> Hi Namhyung,
> Thank you very much for your reply.
> 
> On Tue, Dec 16, 2025 at 1:58 PM Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > > Indeed, as you mentioned in the early discussion, running the
> > > following commands on the host to install certain packages can
> > > successfully compile perf:
> > > > $ sudo apt-get install gcc-aarch64-linux-gnu g++-aarch64-linux-gnu
> > > > $ sudo apt-get install libc6-dev-aarch64-cross linux-libc-dev-aarch64-cross
> > > > $ sudo apt-get install libc6-dev-arm64-cross linux-libc-dev-arm64-cross
> >
> > At this point, I'm confused whether we are talking about general
> > cross-build or just BPF skeleton.  I agree with Leo that the skeleton
> > build should not require any host specific information rather than
> > vmlinux.h.
> >
> 
> I agree with this point. This is also what I was trying to express
> earlier: although installing some additional packages on the host can
> indeed make perf build successfully, in my view this approach is not
> an ideal solution.
> 
> > >
> > >
> > > However, I don’t think relying on the host build environment is the
> > > best approach, for several reasons:
> > >
> > > a) These commands install UAPI header files on the host, especially
> > > `linux-libc-dev-aarch64-cross` and `linux-libc-dev-arm64-cross`. These
> > > headers originate from the kernel source tree’s `include/uapi/` and
> > > `arch/arm64/include/uapi/` directories, and their versions are tied to
> > > the *HOST* kernel version. If the target kernel version is different,
> > > mismatches may cause compilation errors or even runtime failures.
> > >
> > > b) Even if `perf` can be compiled and run successfully now, there is
> > > no guarantee that the kernel source headers will always match the
> > > host-installed UAPI headers as the upstream kernel evolves.
> > >
> > > c) In scenarios where the host acts as a general build server and
> > > needs to build multiple target kernel versions, it is not possible to
> > > ensure that the host UAPI headers are compatible with all target
> > > versions.
> > >
> > > d) As you pointed out, `CLANG_SYS_INCLUDES` does include host headers,
> > > but it uses `-idirafter` instead of `-I`. This means the host headers
> > > have lower priority. This change was introduced in commit a2af0f6b8ef7
> > > ("perf build: Add system include paths to BPF builds"); as noted in
> > > the commit message, the preferred approach is to use kernel source
> > > headers rather than potentially older ones from the system.
> > >
> > >
> > > Based on this, I propose the following include order:
> > > - Prefer kernel source headers
> > >   [RFC] perf build: Use self-contained headers from kernel source when compiling
> > >   https://lore.kernel.org/all/20251124072310.3592-1-hupu.gm@gmail.com/
> > >
> > > - Allow users to specify header search paths matching the target
> > > kernel version (eg. via `EXTRA_BPF_FLAGS`)
> > >   [PATCH] perf build: Support passing extra Clang options via EXTRA_BPF_FLAGS
> > >   https://lore.kernel.org/all/20251013080609.2070555-1-hupu.gm@gmail.com/
> >
> > I'm ok with this part - not only to pass header search paths, it can do
> > anything user wants to add to the compiler.  You may want to send it out
> > in a separate thread with all comments addressed.
> >
> 
> Thank you very much for this suggestion. I understand that you would
> prefer to continue the discussion in a new, separate email thread, and
> I am happy to do so.
> 
> Before proceeding, I would like to clarify your intention to make sure
> I understand it correctly and avoid any misunderstanding. Since the
> discussion above involves two patches with different functionalities,
> I would like to confirm whether you would prefer me to combine these
> two patches into a single one, or to discuss and resend both patches
> together in a new separate email thread.

No, I just want EXTRA_BPF_FLAGS part.  Preferring the kernel source
would need more discussion.

Thanks,
Namhyung

Hi Leo,

Just RESEND this for your attention.

Thanks,
hupu

RESEND for your attention.

RESEND AGAIN

On Mon, Dec 8, 2025 at 5:05 PM hupu <hupu.gm@gmail.com> wrote:
>
> RESEND for your attention.

Hi Namhyung,
Thanks for your review.

On Mon, Oct 20, 2025 at 12:16 PM Namhyung Kim <namhyung@kernel.org> wrote:
>
> On Mon, Oct 20, 2025 at 10:40:49AM +0800, hupu wrote:
> > When cross-compiling perf with BPF enabled, Clang is invoked during the
> > build. Some cross-compilation environments require additional compiler
> > options, such as `--sysroot` or custom include paths.
> >
> > This patch introduces a new Make variable, `EXTRA_BPF_FLAGS`. During BPF
> > skeleton builds, it appends user-provided options to `CLANG_OPTIONS`,
> > allowing extra Clang flags to be set without modifying Makefile.perf
> > directly.
> >
> > Example usage:
> >     EXTRA_BPF_FLAGS="--sysroot=$SYSROOT"
> >     make perf ARCH="$ARCH" EXTRA_BPF_FLAGS="$EXTRA_BPF_FLAGS"
>
> Why not just:
>
>   make perf ARCH="arm64" EXTRA_BPF_FLAGS="--sysroot=..."
>
> >
> > Change history:
> >   v2:
> >     - Rename EXTRA_CLANG_FLAGS to EXTRA_BPF_FLAGS
> >     - Update commit message
> >   v1:
> >     - Introduce EXTRA_CLANG_FLAGS to allow passing extra Clang options
> >
> > Signed-off-by: hupu <hupu.gm@gmail.com>
>
> Leo, are you ok with this?
>
> > ---
> >  tools/perf/Makefile.perf | 5 +++++
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> > index 47c906b807ef..f1f2efdbab8c 100644
> > --- a/tools/perf/Makefile.perf
> > +++ b/tools/perf/Makefile.perf
> > @@ -1249,6 +1249,11 @@ else
> >       $(Q)cp "$(VMLINUX_H)" $@
> >  endif
> >
> > +# Allow users to specify additional Clang options (e.g. --sysroot)
> > +# when cross-compiling BPF skeletons, enabling more flexible
> > +# build configurations.
>
> Can you please move this comment or add new one at the top of the file
> along with EXTRA_CFLAGS?
>

Alright, I will prepare a v3 patch based on your review comments.

Thanks,
hupu

When cross-compiling perf with BPF enabled, Clang is invoked during the
build. Some cross-compilation environments require additional compiler
options, such as `--sysroot` or custom include paths.

This patch introduces a new Make variable, `EXTRA_BPF_FLAGS`. During BPF
skeleton builds, it appends user-provided options to `CLANG_OPTIONS`,
allowing extra Clang flags to be set without modifying Makefile.perf
directly.

Example usage:
    make perf ARCH="arm64" EXTRA_BPF_FLAGS="--sysroot=..."

Change history:
  v3:
    - Move the variable description comment to the top of Makefile.perf
    - Update commit message
  v2:
    - Rename EXTRA_CLANG_FLAGS to EXTRA_BPF_FLAGS
    - Update commit message
  v1:
    - Introduce EXTRA_CLANG_FLAGS to allow passing extra Clang options

Signed-off-by: hupu <hupu.gm@gmail.com>
---
 tools/perf/Makefile.perf | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 47c906b807ef..c1a66cf3d1a7 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -35,6 +35,9 @@ include ../scripts/utilities.mak
 #
 # Define EXTRA_CFLAGS=-m64 or EXTRA_CFLAGS=-m32 as appropriate for
cross-builds.
 #
+# Define EXTRA_BPF_FLAGS="--sysroot=<path>" or other custom include paths for
+# cross-compiling BPF skeletons
+#
 # Define EXCLUDE_EXTLIBS=-lmylib to exclude libmylib from the auto-generated
 # EXTLIBS.
 #
@@ -1249,6 +1252,8 @@ else
  $(Q)cp "$(VMLINUX_H)" $@
 endif

+CLANG_OPTIONS += $(EXTRA_BPF_FLAGS)
+
 $(SKEL_TMP_OUT)/%.bpf.o: $(OUTPUT)PERF-VERSION-FILE
util/bpf_skel/perf_version.h | $(SKEL_TMP_OUT)
 $(SKEL_TMP_OUT)/%.bpf.o: util/bpf_skel/%.bpf.c $(LIBBPF) $(SKEL_OUT)/vmlinux.h
  $(QUIET_CLANG)$(CLANG) -g -O2 -fno-stack-protector --target=bpf \
-- 
2.43.0