Skip to content

tools build: bpf: Append EXTRA_CFLAGS and HOST_EXTRACFLAGS#12293

Open
kernel-patches-daemon-bpf[bot] wants to merge 8 commits into
bpf-next_basefrom
series/1104693=>bpf-next
Open

tools build: bpf: Append EXTRA_CFLAGS and HOST_EXTRACFLAGS#12293
kernel-patches-daemon-bpf[bot] wants to merge 8 commits into
bpf-next_basefrom
series/1104693=>bpf-next

Conversation

@kernel-patches-daemon-bpf

Copy link
Copy Markdown

Pull request for series with
subject: tools build: bpf: Append EXTRA_CFLAGS and HOST_EXTRACFLAGS
version: 2
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=1104693

@kernel-patches-daemon-bpf

Copy link
Copy Markdown
Author

Upstream branch: b93c55b
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1104693
version: 2

@kernel-patches-review-bot

Copy link
Copy Markdown
commit 19bc0e37b0e2f9bb9d4b1d2e59228c83b7d10f54
Author: Leo Yan <leo.yan@arm.com>

selftests/bpf: Use common CFLAGS for urandom_read

The urandom_read helper and its shared library are built with $(CLANG)
directly rather than through the normal selftest $(CC) rules. The CFLAGS
variable can contain specific flags only for $(CC) but might be
imcompatible for $(CLANG) and those flags are not necessarily valid for
the clang-only urandom_read build. Split the BPF selftest local flags
into COMMON_CFLAGS and append them to CFLAGS for the normal build path.
Use COMMON_CFLAGS directly for urandom_read and liburandom_read.so, while
still filtering out -static as before.

> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> index bc049620c774..1e47e29ba421 100644
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile
> @@ -51,7 +51,7 @@ srctree := $(patsubst %/,%,$(dir $(srctree)))
>  srctree := $(patsubst %/,%,$(dir $(srctree)))
>  endif
>
> -CFLAGS += -g $(OPT_FLAGS) -rdynamic -std=gnu11				\
> +COMMON_CFLAGS = -g $(OPT_FLAGS) -rdynamic -std=gnu11				\
>  	  -Wall -Werror -fno-omit-frame-pointer				\
>  	  -Wno-unused-but-set-variable					\
>  	  $(GENFLAGS) $(SAN_CFLAGS) $(LIBELF_CFLAGS)			\
> @@ -64,7 +64,7 @@ LDLIBS += $(LIBELF_LIBS) -lz -lrt -lpthread
>  PCAP_CFLAGS	:= $(shell $(PKG_CONFIG) --cflags libpcap 2>/dev/null && echo "-DTRAFFIC_MONITOR=1")
>  PCAP_LIBS	:= $(shell $(PKG_CONFIG) --libs libpcap 2>/dev/null)
>  LDLIBS += $(PCAP_LIBS)
> -CFLAGS += $(PCAP_CFLAGS)
> +CFLAGS += $(COMMON_CFLAGS) $(PCAP_CFLAGS)

Ian Rogers raised a concern in v4 that COMMON_CFLAGS is being assigned
before 'include ../lib.mk' (which happens later around line 165).

The ../lib.mk include appends important flags to CFLAGS, such as
-D_GNU_SOURCE=. Since COMMON_CFLAGS uses recursive assignment (=), these
flags added by lib.mk should be available when COMMON_CFLAGS expands.
However, COMMON_CFLAGS references $(GENFLAGS), $(SAN_CFLAGS), and
$(LIBELF_CFLAGS) which are defined before lib.mk, but lib.mk may also
modify CFLAGS directly with additional flags.

Will urandom_read miss any flags that lib.mk adds to CFLAGS but that
aren't captured in the variables referenced by COMMON_CFLAGS? Ian
suggested moving these assignments below the include to ensure all
lib.mk-added flags are captured.

Reference:
https://lore.kernel.org/all/CAP-5=fXjd15e5YpCM9KMjEhpjLxvxc6qUk0g7BprCfkzcRZ5_g@mail.gmail.com/

>
>  # Some utility functions use LLVM libraries
>  jit_disasm_helpers.c-CFLAGS = $(LLVM_CFLAGS)

[ ... ]

> @@ -261,7 +261,7 @@ endif
>  $(OUTPUT)/liburandom_read.so: urandom_read_lib1.c urandom_read_lib2.c liburandom_read.map
>  	$(call msg,LIB,,$@)
>  	$(Q)$(CLANG) $(CLANG_TARGET_ARCH) \
> -		     $(filter-out -static,$(CFLAGS) $(LDFLAGS)) \
> +		     $(filter-out -static,$(COMMON_CFLAGS) $(LDFLAGS)) \
>  		     $(filter %.c,$^) $(filter-out -static,$(LDLIBS)) \
>  		     -Wno-unused-command-line-argument \
>  		     -fuse-ld=$(LLD) -Wl,-znoseparate-code -Wl,--build-id=sha1 \

[ ... ]

> @@ -271,7 +271,7 @@ $(OUTPUT)/liburandom_read.so: urandom_read_lib1.c urandom_read_lib2.c liburandom
>  $(OUTPUT)/urandom_read: urandom_read.c urandom_read_aux.c $(OUTPUT)/liburandom_read.so
>  	$(call msg,BINARY,,$@)
>  	$(Q)$(CLANG) $(CLANG_TARGET_ARCH) \
> -		     $(filter-out -static,$(CFLAGS) $(LDFLAGS)) $(filter %.c,$^) \
> +		     $(filter-out -static,$(COMMON_CFLAGS) $(LDFLAGS)) $(filter %.c,$^) \
>  		     -Wno-unused-command-line-argument \
>  		     -lurandom_read $(filter-out -static,$(LDLIBS)) -L$(OUTPUT) \
>  		     -fuse-ld=$(LLD) -Wl,-znoseparate-code -Wl,--build-id=sha1 \



AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

In-Reply-To-Subject: selftests/bpf: Use common CFLAGS for urandom_read
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/26828477669

@kernel-patches-daemon-bpf

Copy link
Copy Markdown
Author

@kernel-patches-daemon-bpf

Copy link
Copy Markdown
Author

Upstream branch: 04de7bc
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1104693
version: 2

@kernel-patches-daemon-bpf

Copy link
Copy Markdown
Author

Upstream branch: c169a2a
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1104693
version: 2

@kernel-patches-daemon-bpf

Copy link
Copy Markdown
Author

Upstream branch: c169a2a
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1104693
version: 2

@kernel-patches-daemon-bpf

Copy link
Copy Markdown
Author

Upstream branch: 8a7f2bf
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1104693
version: 2

@kernel-patches-daemon-bpf

Copy link
Copy Markdown
Author

Upstream branch: bf29346
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1104693
version: 2

@kernel-patches-daemon-bpf

Copy link
Copy Markdown
Author

Upstream branch: 390dc36
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1104693
version: 2

@kernel-patches-daemon-bpf

Copy link
Copy Markdown
Author

Upstream branch: f64c723
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1104693
version: 2

@kernel-patches-daemon-bpf

Copy link
Copy Markdown
Author

Upstream branch: 68f4e48
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1104693
version: 2

@kernel-patches-daemon-bpf

Copy link
Copy Markdown
Author

Upstream branch: c15261b
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1104693
version: 2

@kernel-patches-daemon-bpf

Copy link
Copy Markdown
Author

Upstream branch: 140fa23
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1104693
version: 2

@kernel-patches-daemon-bpf

Copy link
Copy Markdown
Author

Upstream branch: 2e8ad1f
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1104693
version: 2

Leo-Yan added 3 commits June 10, 2026 16:27
bpftool builds a bootstrap libbpf with HOSTCC, but the libbpf submake can
still inherit target build flags through CFLAGS. This can break cross
builds when host objects are compiled with target-only options.

Since HOST_CFLAGS contains warning options that are not suitable for
building libbpf, use LIBBPF_BOOTSTRAP_CFLAGS with the warning options
removed to build the bootstrap libbpf. Clear EXTRA_CFLAGS so target
extra flags are not mixed into the host bootstrap libbpf build.

Signed-off-by: Leo Yan <leo.yan@arm.com>
Acked-by: Quentin Monnet <qmo@kernel.org>
Prepare for future changes where EXTRA_CFLAGS may include flags not
applicable to the host compiler.

Move the HOST_CFLAGS assignment before appending EXTRA_CFLAGS to
CFLAGS so that HOST_CFLAGS does not inherit flags from EXTRA_CFLAGS.

Acked-by: Quentin Monnet <qmo@kernel.org>
Signed-off-by: Leo Yan <leo.yan@arm.com>
Append HOST_EXTRACFLAGS to HOST_CFLAGS so that additional flags can be
applied to the host compiler.

Acked-by: Quentin Monnet <qmo@kernel.org>
Signed-off-by: Leo Yan <leo.yan@arm.com>
@kernel-patches-daemon-bpf

Copy link
Copy Markdown
Author

Upstream branch: 30dee2c
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1104693
version: 2

Leo-Yan added 5 commits June 10, 2026 16:27
tools/scripts/Makefile.include may expand EXTRA_CFLAGS in a future
change.  This could alter the initialization of CFLAGS, as the default
options "-g -O2" would never be set once EXTRA_CFLAGS is expanded.

Prepare for this by moving the CFLAGS initialization before including
tools/scripts/Makefile.include, so it is not affected by the extended
EXTRA_CFLAGS.

Append EXTRA_CFLAGS to CFLAGS only after including Makefile.include and
place it last so that the extra flags propagate properly and can
override the default options.

tools/scripts/Makefile.include already appends $(CLANG_CROSS_FLAGS) to
CFLAGS, the Makefile appends $(CLANG_CROSS_FLAGS) again, remove the
redundant append.

Signed-off-by: Leo Yan <leo.yan@arm.com>
Acked-by: Ihor Solodrai <ihor.solodrai@linux.dev>
Append EXTRA_CFLAGS to CFLAGS so that additional flags can be applied to
the compiler.

Signed-off-by: Leo Yan <leo.yan@arm.com>
ASAN reports stack-buffer-overflow due to the uninitialized op_name.

Initialize it to fix the issue.

Fixes: 054b6c7 ("selftests/bpf: Add verifier log tests for BPF_BTF_LOAD command")
Signed-off-by: Leo Yan <leo.yan@arm.com>
The urandom_read helper and its shared library are built with $(CLANG)
directly rather than through the normal selftest $(CC) rules.

The CFLAGS variable can contain specific flags only for $(CC) but might
be imcompatible for $(CLANG) and those flags are not necessarily valid
for the clang-only urandom_read build.

Split the BPF selftest local flags into COMMON_CFLAGS and append them to
CFLAGS for the normal build path. Use COMMON_CFLAGS directly for
urandom_read and liburandom_read.so, while still filtering out -static as
before.

Signed-off-by: Leo Yan <leo.yan@arm.com>
The BPF selftests prefer static LLVM linking, which works for native
builds but can break cross builds. Its --link-static output may include
host-only libraries that are unavailable for the cross compilation,
causing link failures.

Avoid static LLVM linking for cross builds and use shared LLVM libraries
instead. Native builds keep the existing behavior.

Signed-off-by: Leo Yan <leo.yan@arm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant