From: hupu <hupu.gm@gmail.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Leo Yan <leo.yan@arm.com>, Ian Rogers <irogers@google.com>,
peterz@infradead.org, mingo@redhat.com, acme@kernel.org,
mark.rutland@arm.com, alexander.shishkin@linux.intel.com,
jolsa@kernel.org, adrian.hunter@intel.com, nathan@kernel.org,
nick.desaulniers+lkml@gmail.com, morbo@google.com,
justinstitt@google.com, linux-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org
Subject: Re: [RFC] perf build: Allow passing extra Clang flags via EXTRA_CLANG_FLAGS
Date: Mon, 20 Oct 2025 10:38:17 +0800 [thread overview]
Message-ID: <CADHxFxQHFkn-J9R6AJY8LxkDN-eTWjp34VvoQDcshfZs1eF0rQ@mail.gmail.com> (raw)
In-Reply-To: <aPWNaOqocEPgAJcq@google.com>
Hi Namhyung,
Thanks for your valuable feedback.
On Mon, Oct 20, 2025 at 9:16 AM Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > I’ve tried using EXTRA_CFLAGS and confirm that it doesn’t work. When I
> > build perf with the following command, it still reports errors:
> > make perf ARCH=$ARCH CROSS_COMPILE=$CROSS_COMPILE
> > EXTRA_CFLAGS="--sysroot=$SYSROOT"
>
> Thanks for checking this.
>
> >
> > In fact, by checking the code in tools/perf/Makefile.perf, we can see
> > that the EXTRA_CFLAGS variable is not passed to Clang at all:
> >
> > $(SKEL_TMP_OUT)/%.bpf.o: util/bpf_skel/%.bpf.c $(LIBBPF) $(SKEL_OUT)/vmlinux.h
> > $(QUIET_CLANG)$(CLANG) -g -O2 -fno-stack-protector --target=bpf \
> > $(CLANG_OPTIONS) $(BPF_INCLUDE) $(TOOLS_UAPI_INCLUDE) \
> > -include $(OUTPUT)PERF-VERSION-FILE -include util/bpf_skel/perf_version.h \
> > -c $(filter util/bpf_skel/%.bpf.c,$^) -o $@
> >
> >
> > As shown above, EXTRA_CFLAGS only affects the GCC cross-compilation
> > process and has no impact on the Clang build process.
> > That’s why I proposed introducing an EXTRA_CLANG_FLAGS variable to
> > provide a way to control Clang’s compilation behavior more flexibly.
>
> One thing I care is that we can set clang as a default compiler using CC
> variable then meaning of EXTRA_CFLAGS and EXTRA_CLANG_FLAGS may be
> confusing. I guess EXTRA_BPF_FLAGS is clearer that we want to pass
> something when it builds BPF programs.
>
Indeed, I agree with your suggestion to rename the macro from
EXTRA_CLANG_FLAGS to EXTRA_BPF_FLAGS, as it better reflects that the
options are only intended for building BPF programs.
I will soon send the updated v2 patch with this change.
Thanks,
hupu
next prev parent reply other threads:[~2025-10-20 2:38 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-13 8:06 [RFC] perf build: Allow passing extra Clang flags via EXTRA_CLANG_FLAGS hupu
2025-10-13 8:07 ` hupu
2025-10-13 15:46 ` Ian Rogers
2025-10-13 16:14 ` Leo Yan
2025-10-14 2:31 ` hupu
2025-10-15 9:30 ` Leo Yan
2025-10-15 11:47 ` hupu
2025-10-15 12:55 ` Leo Yan
2025-10-18 10:05 ` hupu
2025-10-19 2:30 ` Namhyung Kim
2025-10-19 7:57 ` hupu
2025-10-20 1:16 ` Namhyung Kim
2025-10-20 2:38 ` hupu [this message]
2025-10-20 2:40 ` [PATCH] perf build: Support passing extra Clang options via EXTRA_BPF_FLAGS hupu
2025-10-20 4:16 ` Namhyung Kim
2025-10-20 8:00 ` hupu
2025-10-20 8:02 ` hupu
2025-10-20 10:15 ` Leo Yan
2025-10-20 12:51 ` hupu
2025-10-20 13:02 ` hupu
2025-10-21 3:11 ` hupu
2025-11-18 7:18 ` hupu
2025-11-18 7:28 ` hupu
2025-11-19 9:43 ` hupu
2025-11-20 19:22 ` Namhyung Kim
2025-11-21 10:17 ` hupu
2025-11-24 7:26 ` hupu
2025-11-24 7:34 ` hupu
2025-11-25 8:13 ` Namhyung Kim
2025-11-25 12:52 ` hupu
2025-11-25 13:07 ` hupu
2025-11-25 16:10 ` Leo Yan
2025-11-26 13:44 ` hupu
2025-12-05 6:33 ` hupu
2025-12-08 9:05 ` hupu
2025-12-10 10:24 ` hupu
2025-12-11 10:39 ` Leo Yan
2025-12-12 6:12 ` hupu
2025-10-20 13:50 ` Leo Yan
2025-10-20 2:45 ` hupu
2025-10-14 1:57 ` [RFC] perf build: Allow passing extra Clang flags via EXTRA_CLANG_FLAGS hupu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CADHxFxQHFkn-J9R6AJY8LxkDN-eTWjp34VvoQDcshfZs1eF0rQ@mail.gmail.com \
--to=hupu.gm@gmail.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=justinstitt@google.com \
--cc=leo.yan@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=morbo@google.com \
--cc=namhyung@kernel.org \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).