Re: [RFC bpf-next 8/9] libbpf: support llvm-generated indirect jumps

[Anton Protopopov <a.s.protopopov@gmail.com>]

On 25/07/08 01:59PM, Eduard Zingerman wrote:
> On Tue, 2025-06-17 at 20:22 -0700, Alexei Starovoitov wrote:
> > On Sun, Jun 15, 2025 at 1:55 AM Anton Protopopov
> > <a.s.protopopov@gmail.com> wrote:
> > > 
> > > The final line generates an indirect jump. The
> > > format of the indirect jump instruction supported by BPF is
> > > 
> > >     BPF_JMP|BPF_X|BPF_JA, SRC=0, DST=Rx, off=0, imm=fd(M)
> > > 
> 
> [...]
> 
> > Uglier alternatives is to redesign the gotox encoding and
> > drop ld_imm64 and *=8 altogether.
> > Then gotox jmp_table[R5] will be like jumbo insn that
> > does *=8 and load inside and JIT emits all that.
> > But it's ugly and likely has other downsides.
> 
> I talked to Alexei and Yonghong off-list, and we seem to be in
> agreement that having a single gotox capturing both the map and the
> offset looks more elegant. E.g.:
> 
>   gotox imm32[dst_reg];
> 
> Where imm32 is an fd of the map corresponding to the jump table,
> and dst-reg is an offset inside the table (it could also be an index).
> 
> So, instead of a current codegen:
> 
>   0000000000000000 <foo>:
>        ...
>        1:       w1 = w1
>        2:       r1 <<= 0x3
>        3:       r2 = 0x0 ll
>                 0000000000000018:  R_BPF_64_64  .BPF.JT.0.0
>        5:       r2 += r1
>        6:       r1 = *(u64 *)(r2 + 0x0)
>        7:       gotox r1
>                 0000000000000038:  R_BPF_64_64  .BPF.JT.0.0
> 
> LLVM would produce:
> 
>   0000000000000000 <foo>:
>        ...
>        1:       w1 = w1
>        2:       r1 <<= 0x3
>        3:       gotox r1
>                 0000000000000038:  R_BPF_64_64  .BPF.JT.0.0
> 
> This sequence leaks a bit less implementation details and avoids a
> check for correspondence between load and gotox instructions.
> It will require using REG_AX on the jit side.
> LLVM side implementation is not hard, as it directly maps to `br_jt`
> selection DAG instruction.
> 
> Anton, wdyt?

I think that this is exactly what I had proposed originally in [1],
so yes, IMO this looks more elegant indeed. (Back then the feedback was
that this is too esoteric, and instead the verifier should be taught
to eat what LLVM generates (<<3 and load).) The instruction can be
extended (SRC and OFF are unused) to support more formats later.

>        3:       gotox r1
>                 0000000000000038:  R_BPF_64_64  .BPF.JT.0.0

How hard is to teach the LLVM to generate this?

  [1] https://lpc.events/event/18/contributions/1941/