Otherwise, we would end up passing `-lNOTFOUND` to the compiler, which
caused various compiler checks to fail and ended up breaking the build
in the most obscure ways. For example, checks for -faligned-allocation
would fail because the compiler would complain about an unknown library
called NOTFOUND, and we would end up not passing -faligned-allocation
anywhere in our build. This is madness.
An even better alternative would be to simply FATAL_ERROR if we don't
find the builtins library. However, it seems like our build has been
working fine without finding it for a while, so instead of making a
bunch of builds fail, we can figure out why linking against compiler-rt
doesn't actually seem to be required in a follow-up, and perhaps
relax that.
This is a variant of D116689 rebased on top of the new (proposed) ABI
refactoring in D120727. It should conserve the basic properties of the
original patch by @phosek, except it also allows cleaning up the merging
of libc++abi into libc++ from the libc++ side.
Differential Revision: https://reviews.llvm.org/D125393
Avoid repeating CMake checks across runtimes by unifying names of
variables used for results to leverage CMake caching.
Differential Revision: https://reviews.llvm.org/D110005
When building libcxx, libcxxabi, and libunwind the build environment may
specify any number of sanitizers. For some build feature tests these
sanitizers must be disabled to prevent spurious linking errors. With
-fsanitize= this is straight forward with -fno-sanitize=all. With
-fsanitize-coverage= there is no -fno-sanitize-coverage=all, but there
is the equivalent undocumented but tested -fsanitize-coverage=0.
The current build rules fail to disable 'trace-pc-guard'. By disabling
all sanitize-coverage flags, including 'trace-pc-guard', possible
spurious linker errors are prevented. In particular, this allows libcxx,
libcxxabi, and libunwind to be built with HonggFuzz.
CMAKE_REQUIRED_FLAGS is extra compile flags when running CMake build
configuration steps (like check_cxx_compiler_flag). It does not affect
the compile flags for the actual build of the project (unless of course
these flags change whether or not a given source compiles and links or
not). So libcxx, libcxxabi, and libunwind will still be built with any
specified sanitize-coverage as before. The build configuration steps
(which are mostly checking to see if certain compiler flags are
available) will not try to compile and link "int main() { return 0;}"
(or other specified source) with sanitize-coverage (which can fail to
link at this stage in building, since the final compile flags required
are yet to be determined).
The change to LIBFUZZER_CFLAGS was done to keep it consistent with the
obvious intention of disabling all sanitize-coverage. This appears to
be intentional, preventing the fuzzer driver itself from showing up in
any coverage calculations.
Reviewed By: #libunwind, #libc, #libc_abi, ldionne, phosek
Differential Revision: https://reviews.llvm.org/D116050
There's a lot of duplicated calls to find various compiler-rt libraries
from build of runtime libraries like libunwind, libc++, libc++abi and
compiler-rt. The compiler-rt helper module already implemented caching
for results avoid repeated Clang invocations.
This change moves the compiler-rt implementation into a shared location
and reuses it from other runtimes to reduce duplication and speed up
the build.
Differential Revision: https://reviews.llvm.org/D88458
There's a lot of duplicated calls to find various compiler-rt libraries
from build of runtime libraries like libunwind, libc++, libc++abi and
compiler-rt. The compiler-rt helper module already implemented caching
for results avoid repeated Clang invocations.
This change moves the compiler-rt implementation into a shared location
and reuses it from other runtimes to reduce duplication and speed up
the build.
Differential Revision: https://reviews.llvm.org/D88458
When `libcxx` or `libcxxabi` is built with `-DLLVM_USE_SANITIZER=MemoryWithOrigins`
**and** `-DLIBCXX[ABI]_USE_COMPILER_RT=ON`, all of the `LIBCXX[ABI]_SUPPORTS_*_FLAG`
checks fail, since the value of `CMAKE_REQUIRED_FLAGS` is not set correctly.
Bugzilla: https://bugs.llvm.org/show_bug.cgi?id=51774
Reviewed By: #libc, #libc_abi, compnerd, ldionne
Differential Revision: https://reviews.llvm.org/D109342
When a target triple is specified in CMake via XXX_TARGET_TRIPLE, we tried
passing the --target=<...> flag to the compiler. However, not all compilers
support that flag (e.g. GCC, which is not a cross-compiler). As a result,
setting e.g. LIBCXX_TARGET_TRIPLE=<host-triple> would end up trying to
pass --target=<host-triple> to GCC, which breaks everything because the
flag isn't even supported.
This commit only adds `--target=<...>` & friends to the flags if it is
supported by the compiler.
One could argue that it's confusing to pass LIBCXX_TARGET_TRIPLE=<...>
and have it be ignored. That's correct, and one possibility would be
to assert that the requested triple is the same as the host triple when
we know the compiler is unable to cross-compile. However, note that this
is a pre-existing issue (setting the TARGET_TRIPLE variable never had an
influence on the flags passed to the compiler), and also fixing that is
starting to look like reimplementing a lot of CMake logic that is already
handled with CMAKE_CXX_COMPILER_TARGET.
Differential Revision: https://reviews.llvm.org/D106082
Let's use -nostdlib++ rather than -nodefaultlibs when building libc++/libc++abi/libunwind libraries. The default is -nostdlib++ if supported by a build compiler like it is the case with clang, otherwise -nodefaultlibs is used as before.
This change is needed to avoid additional changes at the link step and not to increase the maintenance costs. If clang with -nodefaultlibs is used all the libraries which are removed but required would have to be manually added in. This set of libraries are unique and will send out.
The propose change will allow to make the link step simple for other platforms as well.
Reviewed By: #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D95875
Remove check for standalone and shared library mode in libcxxabi to
allow including tests in said mode. This check prevented running the
tests in standalone mode with static libraries, which is the case for
baremetal targets.
Fix check-unwind target trying to use a non-existent llvm-lit executable
in standalone mode. Copy the HandleOutOfTreeLLVM logic from libcxxabi to
libunwind in order to make the tests work in standalone mode.
Reviewed By: ldionne, #libc_abi, #libc
Differential Revision: https://reviews.llvm.org/D86540
Android doesn't have a libgcc_s and uses libgcc instead, so adjust the
build accordingly. This matches compiler-rt's build setup. libc++abi and
libunwind were already checking for libgcc but in a different context.
This change makes them search only for libgcc on Android now, but the
code to link against libgcc if it were present was already there.
Reviewed By: #libc, #libc_abi, #libunwind, rprichard, srhines
Differential Revision: https://reviews.llvm.org/D78787
These are a part of the libc so linking these explicitly isn't necessary
and embedding these as deplibs causes link time error.
This issues was introduced in a9b5fff which changed how we emit deplibs.
Differential Revision: https://reviews.llvm.org/D71135
On Apple platforms, libSystem is an umbrella for all other system
libraries, and libpthread (and friends) are actually just symlinks
to libSystem.
llvm-svn: 373770
Both arm32 armv7/armv8 bots which do not use compiler-rt are failing
to a linking issue:
[100%] Built target cxxabi_static
CMakeFiles/cxxabi_shared.dir/cxa_demangle.cpp.o: In function `(anonymous namespace)::itanium_demangle::OutputStream::writeUnsigned(unsigned long long, bool)':
/home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv7-linux-noexceptions/llvm/projects/libcxxabi/src/demangle/Utility.h:55: undefined reference to `__aeabi_uldivmod'
/home/buildslave/buildslave/libcxx-libcxxabi-libunwind-armv7-linux-noexceptions/llvm/projects/libcxxabi/src/demangle/Utility.h:56: undefined reference to `__aeabi_uldivmod'
clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation)
It seems after r371273 OutputStream is used more extensively and
is pulling OutputStream::writeUnsigned (which thus requires unsigned
integer module).
The straightfoward fix is to explicit link against libgcc if
compiler-rt is not used.
llvm-svn: 372921
These seemed to have been used in the past but were since removed
by the add_compile_flags_if_supported functions that combine these
these checks and adding the flag, but the original checks were never
removed.
Differential Revision: https://reviews.llvm.org/D62566
llvm-svn: 362058
This fixes the issue introduced by r362048 where we always use
pragma comment(lib, ...) for dependent libraries when the compiler
is Clang, but older Clang versions don't support this pragma so
we need to check first if it's supported before using it.
llvm-svn: 362055
This include doesn't seem to be needed for the standalone build (it's
not being used by libc++ build either), but introduces unnecessary
dependency because HandleOutOfTreeLLVM performs checks that require
a working C++ library. We shouldn't require a working C++ library to
build libc++abi or libc++ (it's what we're building after all).
Differential Revision: https://reviews.llvm.org/D58333
llvm-svn: 354284
Refactor the get_llvm_lit_path() logic to respect LLVM_EXTERNAL_LIT,
and require the fallback to be defined explicitly
as LLVM_DEFAULT_EXTERNAL_LIT. This fixes building libcxx standalone
after r346888.
The old logic was using LLVM_EXTERNAL_LIT both as user-defined cache
variable and an optional pre-definition of default value from caller
(e.g. libcxx). It included a hack to make this work by assigning
the value back and forth but it was fragile and stopped working
in libcxx.
The new logic is simpler and more transparent. Default value is
provided in a separate variable, and used only when user-specified
variable is empty (i.e. not overriden).
Differential Revision: https://reviews.llvm.org/D57282
llvm-svn: 352374
The check_library_exists CMake uses a custom symbol definition. This
is a problem when checking for C library symbols because Clang
recognizes many of them as builtins, and returns the
-Wbuiltin-requires-header (or -Wincompatible-library-redeclaration)
error. When building with -Werror which is the default, this causes
the check_library_exists check fail making the build think that C
library isn't available.
To avoid this issue, we should use a symbol that isn't recognized by
Clang and wouldn't cause the same issue. __libc_start_main seems like
reasonable choice that fits the bill.
Differential Revision: https://reviews.llvm.org/D57142
llvm-svn: 352341
This is useful when the static libc++abi library is being linked into
shared libraries that may be used in with other shared libraries that
use different C++ library. We want to avoid avoid exporting libc++abi
or libc++ symbols in those cases. This achieved by a new CMake option
which can be enabled by libc++abi vendors as needed.
Differential Revision: https://reviews.llvm.org/D56026
llvm-svn: 352017
When built within the llvm runtimes directory, the runtimes
CMakeLists.txt adds the same.
Differential Revision: https://reviews.llvm.org/D56979
llvm-svn: 351873
This is needed when cross-compiling for a different target since
CFLAGS may contain additional flags like -resource-dir which
change the location in which compiler-rt builtins are found.
Differential Revision: https://reviews.llvm.org/D54371
llvm-svn: 346820
The paths output from llvm-config --cmakedir and from clang
--print-libgcc-file-name can contain backslashes, while CMake
can't handle the paths in this form.
This matches what compiler-rt already does (since SVN r203789
and r293195).
Differential Revision: https://reviews.llvm.org/D48355
llvm-svn: 335171
This patch updates libc++abi's HandleOutOfTreeLLVM.cmake to match
libc++'s -- and more importantly, to fix a bug where llvm-lit wasn't
found/created when libc++abi was built out-of-tree. This prevented
the test suite from running.
llvm-svn: 322768
Rather than manually checking for support for the spelling of the C++
standard, indicate to CMake that we require that the compiler support
C++11 and that we compile without the GNU extensions. This simplifies
the flags handling in libc++abi itself by relying on CMake to translate
the flag and add it as appropriate.
llvm-svn: 305175
Use the POSITION_INDEPENDENT_CODE target property to indicate that we
should be building with -fPIC or the equivalent flag based on the
toolchain that we are using. This makes the check more portable and
simplifies the flags management. Because we don't want this setting to
propagate in the case of an in-tree build, set the property on the
targets we construct explicitly rather than setting
CMAKE_POSITION_INDEPENDENT_CODE to ON globally.
llvm-svn: 305174
Refactor cmake to remove dependence on LLVM's cmake modules.
This improves handling of cmake checks when cross compiling and brings
libcxxabi in line with libcxx and other project modules.
Differential revision: https://reviews.llvm.org/D33635
llvm-svn: 304374
CMake has the problem with the single dash variant because of the
space, so use the double dash with equal sign version. These flag
need to be included in compile flags to propagate correctly. We also
don't have to pass the target triple when checking for compiler-rt
since that flag is already included in compile flags now.
Differential Revision: https://reviews.llvm.org/D32069
llvm-svn: 300418
Since libc++abi is built with -nodefaultlibs, we should be using this
option even for CMake checks to avoid any inconsistency and also to
avoid dependency on a working C++ standard library just for the setting
up the build itself. The implementation is largely similar to the one
used by libc++.
Differential Revision: https://reviews.llvm.org/D31639
llvm-svn: 299797
Summary: This patch adds a check for if -std=c++11 is a supported flag, and adds it to CMAKE_CXX_FLAGS if it is supported.
Reviewers: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24007
llvm-svn: 280021
Add an option to opt into compiler-rt instead of libgcc. This option defaults
to OFF to avoid a behaviour change. It is not possible to mix and match
different runtime libraries. Disabling this requires that libc++ is built
accordingly. This knob is particularly useful for targets that are GCC by
default (i.e. Linux).
llvm-svn: 275505
This patch breaks the ABI on linux when libc++abi.a is statically linked into
libc++.so. Certain libc++ symbols get exported from libc++abi.a as hidden
and therefore they also get hidden in libc++.so.
The symbols is question are:
* _ZNKSt3__121__basic_string_commonILb1EE20__throw_out_of_rangeEv
* _ZNKSt3__121__basic_string_commonILb1EE20__throw_length_errorEv
* _ZNKSt3__120__vector_base_commonILb1EE20__throw_length_errorEv
I imagine we just need to fix the visibility for these symbols in the libc++
headers but I'm reverting the patch until it's sorted.
llvm-svn: 271500
Enable building libc++abi with hidden visibility by default. The ABI mandated
interfaces (and a few extra) are already set up to be externally visible. This
allows us to ensure that any implementation details are not leaked.
llvm-svn: 270816
Summary:
libgcc_eh.a cannot be used when building libc++abi as a shared library (the default configuration). See this post for some more discussion: https://gcc.gnu.org/ml/gcc/2012-03/msg00104.html
This patch reverts back to using libgcc_s when linking libc++abi.so.
Reviewers: danalbert, chandlerc, mclow.lists, ismail, compnerd
Subscribers: vkalintiris, cfe-commits
Differential Revision: http://reviews.llvm.org/D15440
llvm-svn: 255559
RTTI and exceptions are not needed for the unwinder, the use of C++ there is for
very specific cases, and does not require dynamic_cast nor does it use
exceptions. This avoids unnecessary references to type information being
emitted.
llvm-svn: 228408
The problem that caused the need for http://reviews.llvm.org/D7419 was
caused by testing the value of something that was undefined. This
should prevent that in the future.
llvm-svn: 228257
Without -funwind-tables, the compiler won't generate the unwinding
table for these C functions. However, the functions in libunwind,
such as `_Unwind_Backtrace()`, WILL unwind stack to get the backtrace.
llvm-svn: 226823
Louis Dionne