Re: [PATCH v8 bpf-next 08/11] libbpf: support llvm-generated indirect jumps

[Eduard Zingerman <eddyz87@gmail.com>]

On Tue, 2025-10-28 at 14:20 +0000, Anton Protopopov wrote:
> For v4 instruction set LLVM is allowed to generate indirect jumps for
> switch statements and for 'goto *rX' assembly. Every such a jump will
> be accompanied by necessary metadata, e.g. (`llvm-objdump -Sr ...`):
> 
>        0:       r2 = 0x0 ll
>                 0000000000000030:  R_BPF_64_64  BPF.JT.0.0
> 
> Here BPF.JT.1.0 is a symbol residing in the .jumptables section:
> 
>     Symbol table:
>        4: 0000000000000000   240 OBJECT  GLOBAL DEFAULT     4 BPF.JT.0.0
> 
> The -bpf-min-jump-table-entries llvm option may be used to control the
> minimal size of a switch which will be converted to an indirect jumps.
> 
> Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com>
> Acked-by: Eduard Zingerman <eddyz87@gmail.com>
> ---

The update looks good to me, but I noticed one more thing.

I'm seeing the following messages when rebuilding bpf_gotox using
llvm main, where Yonghong added __BPF_FEATURE_GOTOX.

    CLNG-BPF [test_progs-cpuv4] bpf_gotox.bpf.o
    GEN-SKEL [test_progs-cpuv4] bpf_gotox.skel.h
  libbpf: elf: skipping relo section(13) .rel.jumptables for section(6) .jumptables
  libbpf: elf: skipping relo section(13) .rel.jumptables for section(6) .jumptables

Looking at the llvm-readelf results for the object file:

  Relocation section '.rel.jumptables' at offset 0x5a28 contains 263 entries:
      Offset             Info             Type               Symbol's Value  Symbol's Name
  0000000000000000  0000000300000002 R_BPF_64_ABS64         0000000000000000 syscall
  0000000000000008  0000000300000002 R_BPF_64_ABS64         0000000000000000 syscall
  0000000000000010  0000000300000002 R_BPF_64_ABS64         0000000000000000 syscall
  ...

Note the number of entries (263) above.
When compiled with -S instead of -c, jump tables are printed as:

        .section        .jumptables,"",@progbits
  BPF.JT.4.0:
        .quad   LBB4_5
        .quad   LBB4_4
        ...

Counting these LBBs gives 263 as well, so I assume the relocations are
for label references.

Given that relocation addend is always zero, I don't think we need
these relocations, but I can't figure at the moment, on how to
convince llvm not to emit these.

Yonghong, do you have any ideas?
This is done for OutStreamer->emitValue(Value: LHS, Size: EntrySize);
entries in BPFAsmPrinter::emitJumpTableInfo().

Or I might be wrong and addend is not guaranteed to be zero.
Then we need to handle these on libbpf side.
Spent two hours trying to figure this out, no definite answer yet,
will continue investigation later.

[...]