aboutsummaryrefslogtreecommitdiff
path: root/llvm/unittests/Support/CommandLineTest.cpp
diff options
context:
space:
mode:
authorShoaib Meenai <smeenai@fb.com>2017-12-30 08:00:44 +0000
committerShoaib Meenai <smeenai@fb.com>2017-12-30 08:00:44 +0000
commit0c958fba14bbe65cba7a0dbf5b63a2be2ee75213 (patch)
tree1715cce97b7f7c02d215a26fa80410f768a83171 /llvm/unittests/Support/CommandLineTest.cpp
parent97cc7b037701057b8358953930e31a0f8e72288a (diff)
downloadllvm-0c958fba14bbe65cba7a0dbf5b63a2be2ee75213.zip
llvm-0c958fba14bbe65cba7a0dbf5b63a2be2ee75213.tar.gz
llvm-0c958fba14bbe65cba7a0dbf5b63a2be2ee75213.tar.bz2
[ELF] Only scan executables for shlib undefined symbols
If using a version script with a `local: *` in it, symbols in shared libraries will still get default visibility if another shared library on the link line has an undefined reference to the symbol. This is quite surprising. Neither bfd nor gold have this behavior when linking a shared library, and none of LLD's tests fail without this behavior, so it seems safe to limit scanShlibUndefined to executables. As far as executables are concerned, gold doesn't do any automatic default visibility marking, and bfd issues a link error about a shared library having a reference to a hidden symbol rather than silently giving that symbol default visibility. I think bfd's behavior here is preferable to LLD's, but that's something to be considered in a follow-up. Differential Revision: https://reviews.llvm.org/D41524 llvm-svn: 321578
Diffstat (limited to 'llvm/unittests/Support/CommandLineTest.cpp')
0 files changed, 0 insertions, 0 deletions