Message-ID: <aUD1DXHh_PrCjZ96@google.com>
Date: Mon, 15 Dec 2025 21:58:37 -0800
From: Namhyung Kim <namhyung@...nel.org>
To: hupu <hupu.gm@...il.com>
Cc: Leo Yan <leo.yan@....com>, 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

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

Powered by blists - more mailing lists