[PATCH] D48502: Fix direct calls to __wrap_sym when it is relocated

[Rui Ueyama via llvm-commits]

Thank you for the test files. For convenience, I copy the contents here.

$ cat main.c
void test();
int main() { test(); return 0; }

$ cat test.c
int foo() { return 1; }
int __wrap_foo() { return 0; }
void test() { foo(); __wrap_foo(); }

$ cat run-test
#! /bin/bash
set -x
set -e
clang -fuse-ld=lld -Wl,--wrap=strstr -glldb -Wl,--wrap=foo -shared -o
test.so -fpic test.c
clang -fuse-ld=lld -Wl,--wrap=strstr -glldb -Wl,--wrap=foo -dynamic -o main
-fpic main.c ./test.so
./main


I'm not still very happy about this, but it seems like this is indeed the
only thing we can do with the current architecture. LGTM with some nits.
Thank you for finding and fixing this one!

On Mon, Jul 2, 2018 at 2:10 PM Matthew Koontz via Phabricator <
reviews at reviews.llvm.org> wrote:

> matthew.koontz added a comment.
>
> I've attached a basic program that will crash. It looks like this only
> happens when creating a shared object file, otherwise it gets a direct call
> like you describe. The problem is the `applySymbolWrap` duplicates
> `__wrap_sym`, and then sets the `IsUsedInRegularObj` in one of them to
> false. From then on, these get treated as two separate symbols. I think the
> cause of the runtime crash is setting the `IsUsedInRegularObj` prevents
> adding an entry in the dynamic symbol table, so the lookup fails. Also, the
> former code creates two PLT entries for `__wrap_sym`, when they should
> share a PLT entry since they really are the same symbol.
>
> Ideally, we wouldn't do this memcpy and somehow have all of the references
> to `sym` to now point to `__wrap_sym`, but I can't think of a good way of
> doing that with the current code.
>
> F6562635: lld-test.tar.bz2 <https://reviews.llvm.org/F6562635>
>
>
> Repository:
>   rLLD LLVM Linker
>
> https://reviews.llvm.org/D48502
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180705/8eb0d66a/attachment.html>