[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CADHxFxRrXP+vueYh=pMpGUWXCYUvrju0NO34SFUAB=okfDgpSQ@mail.gmail.com>
Date: Tue, 16 Dec 2025 20:29:04 +0800
From: hupu <hupu.gm@...il.com>
To: Namhyung Kim <namhyung@...nel.org>
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
Hi Namhyung,
Thank you very much for your reply.
On Tue, Dec 16, 2025 at 1:58 PM Namhyung Kim <namhyung@...nel.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
Powered by blists - more mailing lists