On 9/26/26 1:08 AM, David Faust wrote:
Hi Vineet,
On 9/25/26 11:38 AM, Vineet Gupta wrote:
-mxbpf lets the BPF back end generate an indirect call, but the call
patterns emit a single template for both assembly dialects, and the two
dialects do not spell the instruction the same way. In the pseudo-C
dialect, which is the default, the output does not assemble at all:
$ bpf-unknown-none-gcc -mxbpf -O2 -c callx.c
Error: unexpected register name `r0' in instruction `call r0'
This is more than a curiosity now. The Linux kernel just gained support
for the instruction: BPF_JMP | BPF_CALL | BPF_X, `callx dst_reg', is
accepted by the verifier and JITed on x86-64 and arm64 as of [1].
Both LLVM and GCC supported this for a long time, its only getting
exercised now hence the issue.
Thanks. So, we finally get indirect calls :)
Please also send the patches to gcc-patches list for review.
We should figure out some structural changes too.
Historically we have used -mxbpf for enabling features explicitly
_not_ supported in "real" BPF, in order to be able to make use of more
of the GCC testsuite. Note that this is not the same as "experimental".
Now that the real BPF is gaining real support call %rN / callx,
we should move it out from -mxbpf to some normal feature support
options like we have for atomics, signed div, etc.
Will this be part of a BPF ISA v5? v6?
So just so we are on the same page: the v2 series i have locally does
the following
- No longer ties callx to -mxbf (and with this untangling no more
users of -mxbf - which we can decide to remove separately)
- Instead tied to baseline -mcpu=v1 and an additional
-mcallx/-mno-callx (default enabled and addresses concerns about need
for turning off for older kernels)
- Also added a __BPF_FEATURE_CALLX gate (which clang doesn't) - they
can opt-in in future if needed but works well otherwise too as the
canonical gate pattern in selftests is
#ifdef __clang__ || __BPF_FEATURE_CALLX
Let me know if any of this is not acceptable?
Thx,
-Vineet
I also noticed from [1] there are some cases we may need to be
careful around:
- callx to global subprogs, helpers or kfuncs (not allowed)
- tail calls in callees of callx. (Not supported.. yet?)
the details can of course be left for future patches.
Have you started looking into those at all yet?
Ideally we should catch the not-allowed cases in compiler.
Patch 1 fixes the pseudo-c asm template. Also fixes documentation.
Patch 2 fixes the diagnostic "indirect call ... not supported by eBPF".
Tested on a bpf-unknown-none cross compiler: make check-gcc
RUNTESTFLAGS="bpf.exp" gives 602 pass / 6 xfail / 0 fail, against
599 / 6 / 0 before, the three new passes being the added tests.
Also checked by hand that with patch 1 an -mxbpf object assembles in the
default dialect, that libbpf relocates the resulting ld_imm64 of the
function address into a subprog address, and that the kernel then only
rejects it for being older than [1] ("unknown opcode 8d").
[1]
https://lore.kernel.org/bpf/[email protected]/
