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

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

On 25/06/26 07:28PM, Eduard Zingerman wrote:
> On Wed, 2025-06-18 at 12:49 -0700, Eduard Zingerman wrote:
> > On Sun, 2025-06-15 at 08:59 +0000, Anton Protopopov wrote:
> > 
> > [...]
> > 
> > > @@ -698,6 +712,14 @@ struct bpf_object {
> > >  	bool has_subcalls;
> > >  	bool has_rodata;
> > >  
> > > +	const void *rodata;
> > > +	size_t rodata_size;
> > > +	int rodata_map_fd;
> > 
> > This is sort-of strange, that jump table metadata resides in one
> > section, while jump section itself is in .rodata. Wouldn't it be
> > simpler make LLVM emit all jump tables info in one section?
> > Also note that Elf_Sym has name, section index, value and size,
> > hence symbols defined for jump table section can encode jump tables.
> > E.g. the following implementation seems more intuitive:
> > 
> >   .jumptables
> >     <subprog-rel-off-0>
> >     <subprog-rel-off-1> | <--- jump table #1 symbol:
> >     <subprog-rel-off-2> |        .size = 2   // number of entries in the jump table
> >     ...                          .value = 1  // offset within .jumptables
> >     <subprog-rel-off-N>                          ^
> >                                                  |
> >   .text                                          |
> >     ...                                          |
> >     <insn-N>     <------ relocation referencing -'
> >     ...                  jump table #1 symbol
> 
> Anton, Yonghong,
> 
> I talked to Alexei about this yesterday and we agreed that the above
> arrangement (separate jump tables section, separate symbols for each
> individual jump table) makes sense on two counts:
> - there is no need for jump table to occupy space in .rodata at
>   runtime, actual offsets are read from map object;
> - it simplifies processing on libbpf side, as there is no need to
>   visit both .rodata and jump table size sections.
> 
> Wdyt?

Yes, this seems more straightforward. Also this will look ~ the same
for used-defined (= non-llvm-generated) jump tables.

Yonghong, what do you think, are there any problems with this?
Also, how complex this would be to directly link a gotox instruction
to a particular jump table? (For a switch, for "user-defined" jump
tables this is obviously easy to do.)

> > > +
> > > +	/* Jump Tables */
> > > +	struct jt **jt;
> > > +	size_t jt_cnt;
> > > +
> > >  	struct bpf_gen *gen_loader;
> > >  
> > >  	/* Information when doing ELF related work. Only valid if efile.elf is not NULL */
> > 
> > [...]