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

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

On 25/07/03 11:21AM, Eduard Zingerman wrote:
> On Fri, 2025-06-27 at 10:18 +0000, Anton Protopopov wrote:
> > 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.)
> 
> I think I know how to hack this:
> - in BPFAsmPrinter add a function generating a global symbol for jump
>   table (same as MachineFunction::getJTISymbol(), but that one always
>   produces a private symbol (one starting with "L"));
> - override TargetLowering::getPICJumpTableRelocBaseExpr to use the
>   above function;
> - modify BPFMCInstLower::Lower to use the above function;
> - override AsmPrinter::emitJumpTableInfo, a simplified version of the
>   original one:
>   - a loop over all jump tables:
> 	- before each jump table emit start global symbol
> 	- after each jump table emit temporary symbol to mark jt end
> 	- set jump table symbol size to
> 		OutStreamer->emitELFSize(StartSym,
> 		                         MCBinaryExpr::createSub(MCSymbolRefExpr::create(EndSym, OutContext),
> 								 MCSymbolRefExpr::create(StartSym, OutContext),
> 								 OutContext)
> 	- use AsmPrinter::emitJumpTableEntry to emit individual jump table
>       entries;
> - plus the code to create jump tables section.
> 
> I should be able to share the code for this tomorrow or on the weekend.

Would be great, thanks a lot for looking into this! I will
try to address other comments by about the same time. (I am
now in the middle of the list or so.)