On 10/9/26 12:26 AM, Vineet Gupta wrote:
> 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?
That all sounds great. Thanks for addressing the concerns!
Will keep an eye out for v2.
>
> 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]/
