Re: [PATCH v2 05/10] selftests/bpf: Tolerate test file compilation failures

[bot+bpf-ci]

> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> index 72f576a8236a..6a3835a58f87 100644
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile

[ ... ]

> @@ -688,11 +688,14 @@ $(TRUNNER_TEST_OBJS): $(TRUNNER_OUTPUT)/%.test.o:			\
>  		      $(TRUNNER_TESTS_DIR)/%.c				\
>  		      | $(TRUNNER_OUTPUT)/%.test.d
>  	$$(call msg,TEST-OBJ,$(TRUNNER_BINARY),$$@)
> -	$(Q)cd $$(@D) && $$(CC) -I. $$(CFLAGS) -MMD -MT $$@ -c $(CURDIR)/$$< $$(LDLIBS) -o $$(@F)
> +	$(Q)cd $$(@D) && $$(CC) -I. $$(CFLAGS) -MMD -MT $$@ -c $(CURDIR)/$$< $$(LDLIBS) -o $$(@F) || \
> +		($(RM) $$(@F); printf '  %-12s %s\n' 'SKIP-TEST' '$$(notdir $$@)' 1>&2)
>  	$$(if $$(TEST_NEEDS_BTFIDS),						\
> +		if [ -f $$@ ]; then						\
>  		$$(call msg,BTFIDS,$(TRUNNER_BINARY),$$@)			\
>  		$(RESOLVE_BTFIDS) --btf $(TRUNNER_OUTPUT)/btf_data.bpf.o $$@;	\
> -		$(RESOLVE_BTFIDS) --patch_btfids $$@.BTF_ids $$@)
> +		$(RESOLVE_BTFIDS) --patch_btfids $$@.BTF_ids $$@;		\
> +		fi)

When TEST_NEEDS_BTFIDS is set (for resolve_btfids.test.o) and the
object file exists, does the msg macro interact correctly with the
new if guard?

The msg macro in lib.mk expands to:

    msg = @printf '  %-8s%s %s%s\n' ...;

Before this change, $$(call msg,BTFIDS,...) was the first thing in the
$(if) body, so the @ ended up at the start of the recipe line where
make treats it as a "don't echo" prefix and strips it before passing
the command to the shell.

With the if [ -f $$@ ] guard inserted before the msg call, the recipe
line now starts with "if" instead of "@".  Make passes the literal
@printf to the shell, which tries to find a command named @printf:

    /bin/sh -c "if [ -f file ]; then @printf '...' ...; resolve_btfids ...; fi"

This produces a "command not found" error on stderr during every
non-verbose build of resolve_btfids.test.o.  The BTFIDS processing
itself still runs because the semicolons cause the subsequent commands
to execute regardless, but the spurious error is confusing.

One possible fix would be to move the msg call before the if guard,
or strip the @ from the msg expansion when used inside shell control
flow.


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

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/23951016185