[PATCH bpf-next] bpf: Cast helper IDs to the helper type in bpf_helper_defs.h

[PATCH bpf-next] bpf: Cast helper IDs to the helper type in bpf_helper_defs.h

[Maxim Skokov]

bpf_helper_defs.h defines each helper as a function pointer initialized
with a void pointer:

  static long (* const bpf_map_update_elem)(...) = (void *) 2;

Converting void * to a function pointer is a GNU extension in C (gcc
-pedantic: "ISO C forbids initialization between function pointer and
'void *'") and an error in C++, so BPF programs written in C++ can't
include bpf_helpers.h.

Cast to the type of the pointer being defined instead. The name is in
scope in its own initializer, so this works in C and C++:

  static long (* const bpf_map_update_elem)(...) =
	(__typeof__(bpf_map_update_elem)) 2;

The generated code doesn't change.

Assisted-by: LLM
Signed-off-by: Maxim Skokov <skokovmaksimevg@gmail.com>
---
Tested: the generated header compiles with clang for the bpf target as
C, gnu++20 and c++17, and with gcc as C; with gcc -pedantic the 211
function pointer warnings are gone. All 1082 selftests BPF programs
build to byte-identical objects with the old and the new header.

 scripts/bpf_doc.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/bpf_doc.py b/scripts/bpf_doc.py
index 15d113a1bc1d1..6c18aa09389d8 100755
--- a/scripts/bpf_doc.py
+++ b/scripts/bpf_doc.py
@@ -908,7 +908,7 @@ class PrinterHelpersHeader(Printer):
             comma = ', '
             print(one_arg, end='')
 
-        print(') = (void *) %d;' % helper.enum_val)
+        print(') = (__typeof__(%s)) %d;' % (proto['name'], helper.enum_val))
         print('')
 
 
-- 
2.47.3

Re: [PATCH bpf-next] bpf: Cast helper IDs to the helper type in bpf_helper_defs.h

[Alexei Starovoitov]

On Tue, Oct 20, 2026 at 03:12 AM Maxim Skokov <skokovmaksimevg@gmail.com> wrote:
> Converting void * to a function pointer is a GNU extension in C (gcc
> -pedantic: "ISO C forbids initialization between function pointer and
> 'void *'") and an error in C++, so BPF programs written in C++ can't
> include bpf_helpers.h.

What C++ programs you have in mind?
Since today there is one as a selftest.
C++ is far from being supported.

... and including the header doesn't get them far. bpf_for() and bpf_repeat()
in bpf_helpers.h initialize 'struct bpf_iter_num *___p' with (void *)0,
which is an error in C++. The bpf_iter_num_*() externs there have no
extern "C", so the kfunc names get mangled. vmlinux.h doesn't compile
as C++ at all: struct page has a field named private and struct device
has one named class.

> Tested: the generated header compiles with clang for the bpf target as
> C, gnu++20 and c++17, and with gcc as C; with gcc -pedantic the 211
> function pointer warnings are gone. All 1082 selftests BPF programs
> build to byte-identical objects with the old and the new header.

Those are all C programs.

It feels to me that you're scratching the surface.
We have to see full roadmap to decide whether we should even bother
making these steps.

pw-bot: cr

Re: [PATCH bpf-next] bpf: Cast helper IDs to the helper type in bpf_helper_defs.h

[Kumar Kartikeya Dwivedi]

On Wed, 21 Oct 2026 at 02:47, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Tue, Oct 20, 2026 at 03:12 AM Maxim Skokov <skokovmaksimevg@gmail.com> wrote:
> > Converting void * to a function pointer is a GNU extension in C (gcc
> > -pedantic: "ISO C forbids initialization between function pointer and
> > 'void *'") and an error in C++, so BPF programs written in C++ can't
> > include bpf_helpers.h.
>
> What C++ programs you have in mind?
> Since today there is one as a selftest.
> C++ is far from being supported.

Yep, a ton of changes are needed to properly support it.

>
> ... and including the header doesn't get them far. bpf_for() and bpf_repeat()
> in bpf_helpers.h initialize 'struct bpf_iter_num *___p' with (void *)0,
> which is an error in C++. The bpf_iter_num_*() externs there have no
> extern "C", so the kfunc names get mangled. vmlinux.h doesn't compile
> as C++ at all: struct page has a field named private and struct device
> has one named class.

One part is adapting the headers: I've been carrying some of these:
https://github.com/kkdwvd/linux/commits/cpp-bpf-mini
(I replaced my similar bpf_helper_defs.h adjustment with Maxim's).

The other is the vmlinux.h adjustments, there are also various
btf_dump adjustments and other random misc. changes. For vmlinux.h my
approach was to append ___cpp to the keywords and relocate from libbpf
on access to actual field.

https://github.com/kkdwvd/linux/commit/3bb5bb794fa1477ed8ec05f0ffb9b3f9dd9ae3ed

Apart from that, to enable the basics, several adjustments are needed
in the compiler, at the very least recognizing C++ references as
pointers in the ABI in BTF, recognizing preserve_access_index and
fastcall attributes, etc.

>
> > Tested: the generated header compiles with clang for the bpf target as
> > C, gnu++20 and c++17, and with gcc as C; with gcc -pedantic the 211
> > function pointer warnings are gone. All 1082 selftests BPF programs
> > build to byte-identical objects with the old and the new header.
>
> Those are all C programs.
>
> It feels to me that you're scratching the surface.
> We have to see full roadmap to decide whether we should even bother
> making these steps.

Agreed, it's a fair amount of work, and needs discussion on how to
order the changes and whether it makes sense to do it in the first
place given the amount of things that'd need to change.

>
> pw-bot: cr
>

Re: [PATCH bpf-next] bpf: Cast helper IDs to the helper type in bpf_helper_defs.h

[Maxim Skokov]

On Wed, Oct 21, 2026 at 12:42 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> What C++ programs you have in mind?

Programs from projects whose userspace is already C++ and that want to
share types with the BPF side, plus typed maps and RAII for locks,
kptrs and ring buffer reservations. Not full C++: no exceptions, RTTI
or virtual calls. I'm building that as a small header-only library on
top of libbpf: https://github.com/cpp-bpf/cpp-bpf

> We have to see full roadmap to decide whether we should even bother
> making these steps.

Fair. The compiler has to come first, and I've started there:

- BTF and CO-RE for C++ records, which crash clang since LLVM 22.1 for
  any record with methods or bases, and references as pointers in BTF
  are in review: llvm/llvm-project#233715. Reviews welcome.
- Next: preserve_access_index, btf_decl_tag, btf_type_tag and
  bpf_fastcall, which are C-only in clang today.

On the kernel side:

- BPF-side headers: Kumar's cpp-bpf-mini series.
- vmlinux.h: a C++ mode in btf_dump. Generating one for 6.12 and
  bpf-next, keyword suffixes weren't enough: tags clashing with
  typedefs, anonymous members of a named struct type (-fms-extensions),
  members hiding a typedef of the same name, enum forward declarations,
  and empty structs, which have size 1 in C++ and silently shift the
  members after them (e.g. lock_class_key without lockdep).
- Tests: C++ selftests, and a check that C and C++ see the same layout
  for every type in vmlinux.h.

Kumar, I can send the vmlinux.h cases above as patches on top of your
btf_dump change, and I'd be glad to split the compiler items too if
you want to take some of them. How do you plan to order this?