Add a linker test for -Bsymbolic-functions to AddLLVM and remove
the illumos hardcoded bits for its handling. OpenBSD also has a
local patch for linking with the old BFD linker on mips64 and
sparc64.
There was a build bot failure on AIX after #116556, and who knows what
other systems don't support symbol versioning. So let's limit this to
Linux for now. We can always add more cases later.
It seems we can get there with MSVC if LLVM_BUILD_LLVM_DYLIB_VIS is set.
Slightly surprising because I didn't know that MSVC supports the flag
-Bsymbolic-functions, but let's play it safe.
The situation that required symbol versions on the LLVM shared library
can also happen for clang-cpp, although it is less common: different
tools require different versions of the library, and through transitive
dependencies a process ends up with multiple copies of clang-cpp. This
causes havoc with ELF, because calls meant to go one version of the
library end up with another.
I've also considered introducing a symbol version globally, but for
example the clang (C) library and other targets outside of LLVM/Clang,
e.g. libc++, would not want that. So it's probably best if we keep it to
those libraries.
This reverts commit 944478dd62a78f6bb43d4da210643affcc4584b6.
Reverted because of following error on greendragon
ld: unknown options: --version-script
clang: error: linker command failed with exit code 1 (use -v to see invocation)
The situation that required symbol versions on the LLVM shared library
can also happen for clang-cpp, although it is less common: different
tools require different versions of the library, and through transitive
dependencies a process ends up with multiple copies of clang-cpp. This
causes havoc with ELF, because calls meant to go one version of the
library end up with another.
I've also considered introducing a symbol version globally, but for
example the clang (C) library and other targets outside of LLVM/Clang,
e.g. libc++, would not want that. So it's probably best if we keep it to
those libraries.
illumos has an older version of the Solaris linker that does not
support the GNU version script compat nor version scripts and does
not support -Bsymbolic-functions. Treat illumos linker separately.
The libclang/CMakeLists part lifted from NetBSD's pkgsrc.
Build tested on Solaris 11.4 and OpenIndiana 2023.10.
/usr/bin/ld --version
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.3260
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1790 (illumos)
This fixes two issues that are observed after
5111286f06e1e10f24745007a45a830760f1790c:
For builds with GCC with LLVM_LINK_LLVM_DYLIB=ON, we previously got
build errors, as libclang-cpp.dll suddenly only contained the
functions that were marked dllexport via REPL_EXTERNAL_VISIBILITY,
instead of all symbols as expected.
For MinGW builds with Clang, building previously succeeded (as it
used either the __attribute__((visibility("default"))) annotation or
nothing at all), and the functions were exported from libclang-cpp.dll
if that was built, but the unit test failed (as neither of those cases
made the functions exported from an EXE).
Don't use the visibility attributes on MinGW targets for these purposes;
setting default visibility only makes a difference if building with
e.g. -fvisibility=hidden, but it doesn't make the symbols exported
from an EXE.
Differential Revision: https://reviews.llvm.org/D151620
I went over the output of the following mess of a command:
(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z |
parallel --xargs -0 cat | aspell list --mode=none --ignore-case |
grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n |
grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less)
and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).
Differential Revision: https://reviews.llvm.org/D130827
This is an ELF specific option which isn't supported for Windows/MinGW
targets, even if the MinGW linker otherwise uses an ld.bfd like linker
interface.
Differential Revision: https://reviews.llvm.org/D105148
llvm-dev message: https://lists.llvm.org/pipermail/llvm-dev/2021-May/150465.html
In an ELF shared object, a default visibility defined symbol is preemptible by
default. This creates some missed optimization opportunities.
-Bsymbolic-functions is more aggressive than our current -fvisibility-inlines-hidden
(present since 2012) as it applies to all function definitions. It can
* avoid PLT for cross-TU function calls && reduce dynamic symbol lookup
* reduce dynamic symbol lookup for taking function addresses and optimize out GOT/TOC on x86-64/ppc64
In a -DLLVM_TARGETS_TO_BUILD=X86 build, the number of JUMP_SLOT decreases from 12716 to 1628, and the number of GLOB_DAT decreases from 1918 to 1313
The built clang with `-DLLVM_LINK_LLVM_DYLIB=on -DCLANG_LINK_CLANG_DYLIB=on` is significantly faster.
See the Linux kernel build result https://bugs.archlinux.org/task/70697
Note: the performance of -fno-semantic-interposition -Bsymbolic-functions
libLLVM.so and libclang-cpp.so is close to a PIE binary linking against
`libLLVM*.a` and `libclang*.a`. When the host compiler is Clang,
-Bsymbolic-functions is the major contributor. On x86-64 (with GOTPCRELX) and
ppc64 ELFv2, the GOT/TOC relocations can be optimized.
Some implication:
Interposing a subset of functions is no longer supported.
(This is fragile on ELF and unsupported on Mach-O at all. For Mach-O we don't
use `ld -interpose` or `-flat_namespace`)
Compiling a program which takes the address of any LLVM function with
`{gcc,clang} -fno-pic` and expects the address to equal to the address taken
from libLLVM.so or libclang-cpp.so is unsupported. I am fairly confident that
llvm-project shouldn't have different behaviors depending on such pointer
equality (as we've been using -fvisibility-inlines-hidden which applies to
inline functions for a long time), but if we accidentally do, users should be
aware that they should not make assumption on pointer equality in `-fno-pic`
mode.
See more on https://maskray.me/blog/2021-05-09-fno-semantic-interposition
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D102090
llvm-dev message: https://lists.llvm.org/pipermail/llvm-dev/2021-May/150465.html
In an ELF shared object, a default visibility defined symbol is preemptible by default.
This creates some missed optimization opportunities. -fno-semantic-interposition can optimize -fPIC:
* in Clang: avoid GOT/PLT cost for variable access/function calls to external linkage definition in the same TU
* in GCC: enable interprocedural optimizations (including inlining) and avoid PLT
See https://gist.github.com/MaskRay/2d4dfcfc897341163f734afb59f689c6 for more information.
-Bsymbolic-functions is more aggressive than -fvisibility-inlines-hidden (present since 2012) as it applies
to all function definitions. It can
* avoid PLT for cross-TU function calls && reduce dynamic symbol lookup
* reduce dynamic symbol lookup for taking function addresses and optimize out GOT/TOC on x86-64/ppc64
With both options, the libLLVM.so and libclang-cpp.so performance should
be closer to PIE binary linking against `libLLVM*.a` and `libclang*.a`
(In a -DLLVM_TARGETS_TO_BUILD=X86 build, the number of JUMP_SLOT decreases from 12716 to 1628, and the number of GLOB_DAT decreases from 1918 to 1313
The built clang with `-DLLVM_LINK_LLVM_DYLIB=on -DCLANG_LINK_CLANG_DYLIB=on` is significantly faster.
See the Linux kernel build result https://bugs.archlinux.org/task/70697
)
Some implication:
Interposing a subset of functions is no longer supported.
(This is fragile anyway and cannot really be supported. For Mach-O we don't use
`ld -interpose`, so interposition is not supported on Mach-O at all.)
Compiling a program which takes the address of any LLVM function with
`{gcc,clang} -fno-pic` and expects the address to equal to the address taken
from libLLVM.so or libclang-cpp.so is unsupported. I am fairly confident that
llvm-project shouldn't have different behaviors depending on such pointer
equality (as we've been using -fvisibility-inlines-hidden which applies to
inline functions for a long time), but if we accidentally do, users should be
aware that they should not make assumption on pointer equality in `-fno-pic`
mode.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D102090
Summary:
If we are building static libraries we don't need to link them into
clang-shlib, since clang-shlib already has all the individual object
files linked in.
Reviewers: smeenai
Reviewed By: smeenai
Subscribers: mgorny, cfe-commits, llvm-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D82694
Summary:
We were linking all the clang objects and shared libraries into
libclang-cpp.so, which was causing the command line options to be
registered twice.
Reviewers: beanz, mgorny
Reviewed By: beanz, mgorny
Subscribers: merge_guards_bot, mgorny, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68520
Summary:
We were linking all the clang objects and shared libraries into
libclang-cpp.so, which was causing the command line options to be
registered twice.
Reviewers: beanz, mgorny
Reviewed By: beanz, mgorny
Subscribers: mgorny, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68520
Undoes some of the effects of r360946 when using the Xcode CMake
generator---it doesn't handle object libraries correctly at all.
Attempts to still honor BUILD_SHARED_LIBS for Xcode, but I didn't
actually test it. Should have no effect on non-Xcode generators.
https://reviews.llvm.org/D68430
llvm-svn: 373769
This reverts r365825 (git commit 3173c60f96c3ccfc17d403a192ae58e720153c23)
This is breaking BUILD_SHARED_LIBS=ON builds. Reverting while I rethink it.
llvm-svn: 365922
Summary:
If CLANG_LINK_CLANG_DYLIB is also enabled, then this library needs to be
installed.
Fixes PR42575.
Reviewers: beanz, smeenai
Subscribers: mgorny, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64582
Conflicts:
clang/tools/clang-shlib/CMakeLists.txt
llvm-svn: 365905
Any static library with a PRIVATE dependency ends up with a
$<LINK_ONLY:...> generator expression in its INTERFACE_LINK_LIBRARIES,
which won't be evaluated by the $<TARGET_PROPERTY:...>, so we end up
with an unevaluated generator expression in the generated build file and
Ninja chokes on the dollar sign. Just use the static library directly
for its dependencies instead of trying to propagate dependencies
manually.
Differential Revision: https://reviews.llvm.org/D64579
llvm-svn: 365825
Public and Private link libraries get merged in the LINK_LIBRARIES property instead of being kept separate.
With any luck this will get `BUILD_SHARED_LIBS` working again on Linux.
llvm-svn: 361334
If clang's libraries are build SHARED, we need to grab their `PRIVATE_LINK_LIBRARIES` properties and add those to clang_shared's interface.
llvm-svn: 361275
Summary:
This patch adds a libClang_shared library on *nix systems which exports the entire C++ API. In order to support this on Windows we should really refactor llvm-shlib and share code between the two.
This also uses a slightly different method for generating the shared library, which I should back-port to llvm-shlib. Instead of linking the static archives and passing linker flags to force loading the whole libraries, this patch creates object libraries for every library (which has no cost in the build system), and link the object libraries.
llvm-svn: 360985
Summary:
This patch adds a libClang_shared library on *nix systems which exports the entire C++ API. In order to support this on Windows we should really refactor llvm-shlib and share code between the two.
This also uses a slightly different method for generating the shared library, which I should back-port to llvm-shlib. Instead of linking the static archives and passing linker flags to force loading the whole libraries, this patch creates object libraries for every library (which has no cost in the build system), and link the object libraries.
Reviewers: tstellar, winksaville
Subscribers: mgorny, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61909
llvm-svn: 360946
