mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: bot+bpf-ci@kernel.org
To: hackerowskiy@gmail.com,bpf@vger.kernel.org
Cc: ast@kernel.org,daniel@iogearbox.net,andrii@kernel.org,eddyz87@gmail.com,memxor@gmail.com,martin.lau@linux.dev,song@kernel.org,yonghong.song@linux.dev,jolsa@kernel.org,emil@etsalapatis.com,ihor.solodrai@linux.dev,linux-kernel@vger.kernel.org,hackerowskiy@gmail.com,ast@kernel.org,andrii@kernel.org,daniel@iogearbox.net,martin.lau@kernel.org,eddyz87@gmail.com,yonghong.song@linux.dev,mason@kernel.org,ihor.solodrai@linux.dev
Subject: Re: [PATCH] libbpf: fix helper macro C++ compatibility
Date: Sat, 24 Oct 2026 04:36:19 +0000 (UTC)	[thread overview]
Message-ID: <7fe212a5137bf5211aef0a489098fa17f460e7cbc307afb2ca434af4674126bd@mail.kernel.org> (raw)
In-Reply-To: <20261024035902.44566-1-hackerowskiy@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6125 bytes --]

> libbpf: fix helper macro C++ compatibility

TL;DR:
- bpf_for() and bpf_repeat() may still fail to compile in C++ (void *
  initializer left unchanged)
- Fixes: tag looks inaccurate and would pull this into stable trees
- Nit: generated-header comment misplaced

>     libbpf: fix helper macro C++ compatibility
>
>     C++26 warns about the GNU named variadic parameter syntax in
>     bpf_helpers.h, which prevents consumers from using the header with
>     -Werror=variadic-macros. Replace the named parameters with __VA_ARGS__.
>
>     C++ also rejects implicit conversions used by helper argument packing,
>     bpf_for_each, and generated helper function pointers. Use explicit
>     integer and typed pointer casts so these helpers can be parsed and used
>     from C++.
>
>     Verified with GCC and Clang C++26 syntax checks using helper macros,
>     an ARM64-targeted BPF C smoke build, and generated helper definitions
>     from scripts/bpf_doc.py. checkpatch.pl reports no errors or warnings.
>
>     AI assistance: OpenAI Codex helped reproduce the C++26 failures and
>     draft changes to tools/lib/bpf/bpf_helpers.h and scripts/bpf_doc.py.
>     The human submitter must review the changes and test results before
>     submission.
>
>     Fixes: d6a6a55518c1 ("libbpf: Move BPF_SEQ_PRINTF and BPF_SNPRINTF to bpf_helpers.h")
>     Closes: https://github.com/libbpf/libbpf/issues/974
>     Signed-off-by: Eduard Zateev <hackerowskiy@gmail.com>

Is this Fixes: tag accurate?

d6a6a55518c1 only moved BPF_SEQ_PRINTF and BPF_SNPRINTF from bpf_tracing.h
to bpf_helpers.h.  Their args... syntax came from c09add2fbc5a
("tools/libbpf: Add bpf_iter support").

The other constructs changed here came from different commits:

  - bpf_printk()'s args... and ##args from c2758baa9798 ("libbpf: Modify
    bpf_printk to choose helper based on arg count")
  - bpf_for_each()'s (void *)0 initializer from the open-coded iterator
    work, moved into bpf_helpers.h by c5e647416708
  - the "(void *) %d" helper initializer in the generated header from
    7a387bed47f7 ("scripts/bpf: teach bpf_helpers_doc.py to dump BPF
    helper definitions")

None of those commits broke C++ support for the header.  It never had C++
support, so this patch looks like it adds it rather than fixing a
regression.

The tag would also mark this change for stable trees back to v5.14, many of
which do not have bpf_for_each(), bpf_stream_printk() or __bpf_vprintk().

Should the Fixes: tag be dropped, given that Closes: already gives the
motivation?

> diff --git a/scripts/bpf_doc.py b/scripts/bpf_doc.py
> index 15d113a1bc1d..02e31ad509af 100755
> --- a/scripts/bpf_doc.py
> +++ b/scripts/bpf_doc.py
> @@ -829,6 +829,11 @@ class PrinterHelpersHeader(Printer):
>  /* Forward declarations of BPF structs */'''
>  
>          print(header)
> +        print("#ifdef __cplusplus")
> +        print("#define ___bpf_helper_stub(id, name) reinterpret_cast<decltype(+name)>(id)")
> +        print("#else")
> +        print("#define ___bpf_helper_stub(id, name) ((void *)(id))")
> +        print("#endif")
>          for fwd in self.type_fwds:
>              print('%s;' % fwd)
>          print('')

This isn't a bug, but the header string ends with the comment
"/* Forward declarations of BPF structs */", and this new block is printed
right after it, before the struct declarations.  The generated
bpf_helper_defs.h now reads:

    /* Forward declarations of BPF structs */
    #ifdef __cplusplus
    #define ___bpf_helper_stub(id, name) reinterpret_cast<decltype(+name)>(id)
    #else
    #define ___bpf_helper_stub(id, name) ((void *)(id))
    #endif
    struct bpf_fib_lookup;

So the comment now sits on top of the macro block instead of the forward
declarations.  Could the #ifdef block be printed before the comment, or after
the forward declarations and the blank line, so the comment stays next to the
declarations it describes?

[ ... ]

> @@ -382,16 +403,18 @@ extern void bpf_iter_num_destroy(struct bpf_iter_num *it) __weak __ksym;
>   * extension: __attribute__((cleanup(<func>))), supported by both GCC and
>   * Clang.
>   */
> -#define bpf_for_each(type, cur, args...) for (							\
> +#define bpf_for_each(type, cur, ...) for (							\
>  	/* initialize and define destructor */							\
>  	struct bpf_iter_##type ___it __attribute__((aligned(8), /* enforce, just in case */,	\
>  						    cleanup(bpf_iter_##type##_destroy))),	\
>  	/* ___p pointer is just to call bpf_iter_##type##_new() *once* to init ___it */		\
>  			       *___p __attribute__((unused)) = (				\
> -					bpf_iter_##type##_new(&___it, ##args),			\
> +						bpf_iter_##type##_new(&___it, \
> +								       ##__VA_ARGS__), \
>  	/* this is a workaround for Clang bug: it currently doesn't emit BTF */			\
>  	/* for bpf_iter_##type##_destroy() when used from cleanup() attribute */		\
> -					(void)bpf_iter_##type##_destroy, (void *)0);		\
> +					(void)bpf_iter_##type##_destroy, \
> +					(struct bpf_iter_##type *)0); \
>  	/* iteration and termination check */							\
>  	(((cur) = bpf_iter_##type##_next(&___it)));						\
>  )

The commit message says C++ rejects the implicit conversions used by
bpf_for_each(), and this changes its ___p initializer from (void *)0 to
(struct bpf_iter_##type *)0.  The sibling macros bpf_for() and bpf_repeat()
still end their ___p initializer with:

    (void)bpf_iter_num_destroy, (void *)0);

___p is declared as struct bpf_iter_num * there (in the same declaration as
___it), and C++ does not allow an implicit conversion from void * to
struct bpf_iter_num *.

Won't a C++ BPF program that uses bpf_for(i, 0, N) or bpf_repeat(N) still
fail to compile with the same error this patch fixes for bpf_for_each()?
Since the stated goal is that "these helpers can be parsed and used from
C++", should bpf_for() and bpf_repeat() get the same
(struct bpf_iter_num *)0 change?


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

  reply	other threads:[~2026-10-24  4:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-24  3:59 Eduard Zateev
2026-10-24  4:36 ` bot+bpf-ci [this message]
2026-10-24 19:16 ` Alexei Starovoitov

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=7fe212a5137bf5211aef0a489098fa17f460e7cbc307afb2ca434af4674126bd@mail.kernel.org \
    --to=bot+bpf-ci@kernel.org \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=emil@etsalapatis.com \
    --cc=hackerowskiy@gmail.com \
    --cc=ihor.solodrai@linux.dev \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=mason@kernel.org \
    --cc=memxor@gmail.com \
    --cc=song@kernel.org \
    --cc=yonghong.song@linux.dev \
    /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

all inboxes | Powered by JetHome®