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.)
