linux-kernel - Re: [PATCH] perf build: Support passing extra Clang options via EXTRA_BPF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADHxFxQjMy9n7G1dUX=HLi3b5VFjMd8YpBP7DOQyOdaQp443mA@mail.gmail.com>
Date: Mon, 20 Oct 2025 20:51:52 +0800
From: hupu <hupu.gm@...il.com>
To: Leo Yan <leo.yan@....com>, Namhyung Kim <namhyung@...nel.org>
Cc: acme@...nel.org, adrian.hunter@...el.com, 
	alexander.shishkin@...ux.intel.com, irogers@...gle.com, jolsa@...nel.org, 
	justinstitt@...gle.com, linux-kernel@...r.kernel.org, 
	linux-perf-users@...r.kernel.org, mark.rutland@....com, mingo@...hat.com, 
	morbo@...gle.com, nathan@...nel.org, nick.desaulniers+lkml@...il.com, 
	peterz@...radead.org
Subject: Re: [PATCH] perf build: Support passing extra Clang options via EXTRA_BPF_FLAGS

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