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

[Eduard Zingerman <eddyz87@gmail.com>]

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.