[PATCH] D13501: [ELF2] Add -wrap switch

Rui Ueyama via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 7 07:22:20 PDT 2015


On Wed, Oct 7, 2015 at 6:59 AM, Igor Kudrin <ikudrin.dev at gmail.com> wrote:

> ikudrin added a comment.
>
> In http://reviews.llvm.org/D13501#261600, @ruiu wrote:
>
> > This patch needs redesigning because we don't want to look up hash
> tables more than once for each symbol. In this patch, names for undefined
> symbols are looked up twice -- once in the InputFile.cpp and the other in
> SymbolTable.cpp.
>
>
> We have to look up for different names for defined and undefined symbols,
> so we can't use just one hash map.
>
> In most cases, when the -wrap switch is not used and
> UndefSymNameReplacement is empty, addition lookup will be very cheap,
> without calculating a hash value at all. On the other hand, we can use just
> std::map which expected to work really quick in our case.
>
>
No, we don't have to look up hash table more than once. I thought a bit
more about this and noticed that the LLD architecture (the separation of
Symbol and SymbolBody) would really play well here. Symbols are just
pointers to SymbolBodies, and symbol renaming is as easy as single pointer
mutation. Here's the idea.

First we resolve all symbols without considering --wrap option (so no
overhead for --wrap during file parsing and symbol resolution). When symbol
resolution is done, we basically have three Symbols for --wrap'ed symbol S
in the symbol table: S, __wrap_S, and __real_S. Let X, Y and Z be their
SymbolBodies, respectively.

Originally the relationships are

  S -> X
  __wrap_S -> Y
  __real_S -> Z

We swap the pointers so that their relationships are

  S -> Y
  __wrap_S -> Y
  __real_S -> X

Now you can see that all symbols that would have been resolved to S without
--wrap are now resolved as if they were __wrap_S. __real_S is also properly
resolved to the symbol that was once the real symbol pointed to. This is
the same result as what --wrap expects.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151007/429f1314/attachment.html>


More information about the llvm-commits mailing list