Message-ID: <CADHxFxTHYwjqAjURTbkZ=6-4Ti0GGc7uKsrjthL9s78rAgv5EA@mail.gmail.com>
Date: Mon, 20 Oct 2025 21:02:49 +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

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

Powered by blists - more mailing lists