[PATCH] D20645: Avoid doing binary search.

[Rafael Espíndola via llvm-commits]

On 26 May 2016 at 15:22, Rui Ueyama <ruiu at google.com> wrote:
> ruiu added a comment.
>
> Not directly related to this patch, and I'm not suggesting we should do it, but here's one radical idea that could make the mergeable section handling a lot faster: instead of storing mergeable strings into sections, make them symbols and handle symbol names as symbol contents. For example, for a mergeable string "foobar", a compiler create a symbol ".merge.foobar". When a linker see a symbol that starts with ".merge." prefix (or with a special symbol type), it creates section contents just like as it reserves space in .bss for common symbols by copying the symbol name to the section, and set the symbol's address to the address in the section.
>
> The symbol table is the single central repository to identify and uniquify pieces of data and mergeable strings can piggyback on it.  I think this way is a lot faster than the current scheme to merge strings using mergeable sections.

We chatted a bit about this during BSDCan.  The general idea is to
change shouldRelocateWithSymbol to return true for every symbol in a
mergeable section. It is ok to just keep the symbol name of .Lstr*. At
some point we should get a general solution to avoid creating unique
names for these.

In lld then Symbol gets a new member that contains the offset of the
symbol in the output section. We can then use that instead of
InputSectionBase<ELFT>::getOffset(const DefinedRegular<ELFT> &Sym).

Cheers,
Rafael