Re: [PATCH] perf build: Support passing extra Clang options via EXTRA_BPF_FLAGS

[Namhyung Kim <namhyung@kernel.org>]

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