Re: [PATCH v1 0/7] perf symbol: Reference counting, flat array storage, and LRU shrinking

[Alireza Haghdoost]

> > That is close to what patch 5/6 of my v3 does. Its index is a sorted
> > array of fixed-size entries:
> >
> >    struct sym_idx {
> >            u64     start;
> >            u64     end;
> >            u32     name_off;
> >            u8      binding;
> >            u8      type;
> >            u8      flags;
> >    };
> >
> > That is 24 bytes per symbol. The name is read from the string table
> > and demangled only when a sample lands in the symbol. The difference
> > from your description is that v3 then creates a regular struct symbol
> > for the hit and inserts it in the rb-tree, because the rest of perf
> > holds struct symbol pointers. If the entry itself were the symbol,
> > with the name as a pointer/offset union, that extra step would go
> > away. Ian's patch 1 would help: once every name access goes through
> > symbol__name(), that accessor is the only place that has to resolve
> > an offset.
>
> I'm curious if name_off would work well for PLT symbols which come from
> the dynamic symbol table.  Probably you need to handle them differently.
>

Hi Namhyung,

Yes, synthesized PLT symbols need separate handling, but current
upstream already has that path and my v3 series keeps it.

For a regular ELF symbol, name_off is its st_name: a byte offset into
.strtab for .symtab, or .dynstr for .dynsym. So the same index format
works for both tables. v3 uses .dynsym when a DSO has no .symtab.

An @plt symbol is synthesized rather than read directly from either
symbol table. Upstream's dso__synthesize_plt_symbols() gets its address
from the .plt layout, finds its base name through .rela.plt and
.dynsym, and appends "@plt". The existing code also handles .plt.got
and .plt.sec this way.

Since name_off only identifies the base string, it cannot represent
the added "@plt" suffix by itself. I think we should keep synthesizing
these as regular symbols, as upstream does now. v3 only makes the byte
cap apply to them and, in lazy mode, clips the index at .plt so a
preceding zero-size symbol cannot overlap the PLT entries. With the cap
disabled, which is the default, PLT synthesis is unchanged.

There aren't many of them. On the sample fixture, has 381
.rela.plt entries against about 319,000 .symtab symbols, and the other
binary has 100 against about 637,000. Therefore, I think keeping the existing
upstream path has little memory cost compared with the main symbol table.

Thanks,
Alireza