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?
> > +
> > + /* 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 */
>
> [...]
