summaryrefslogtreecommitdiff
path: root/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* [compiler-rt] Don't use libcxx if it's not enabled by LLVM_ENABLE_PROJECTSVitaly Buka2019-08-281-18/+24
| | | | | | | | | This fixes sanitizer-x86_64-linux-fuzzer which switched to new layout and not it can't link as libcxx is always there. We should support and tests libcxx but still it was unexpected that libfuzzer ignored LLVM_ENABLE_PROJECTS_USED. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@370153 91177308-0d34-0410-b5e6-96231b3b80d8
* Add GWP-ASan fuzz target to compiler-rt/tools.Mitch Phillips2019-08-271-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: @eugenis to approve addition of //compiler-rt/tools. @pree-jackie please confirm that this WFY. D66494 introduced the GWP-ASan stack_trace_compressor_fuzzer. Building fuzz targets in compiler-rt is a new affair, and has some challenges: - If the host compiler doesn't have compiler-rt, the -fsanitize=fuzzer may not be able to link against `libclang_rt.fuzzer*`. - Things in compiler-rt generally aren't built when you want to build with sanitizers using `-DLLVM_USE_SANITIZER`. This tricky to work around, so we create the new tools directory so that we can build fuzz targets with sanitizers. This has the added bonus of fixing the problem above as well, as we can now just guard the fuzz target build to only be done with `-DLLVM_USE_SANITIZE_COVERAGE=On`. Reviewers: eugenis, pree-jackie Reviewed By: eugenis, pree-jackie Subscribers: dberris, mgorny, #sanitizers, llvm-commits, eugenis, pree-jackie, lebedev.ri, vitalybuka, morehouse Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D66776 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@370094 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sanitizer] Disable -Wframe-larger-than on SystemZUlrich Weigand2019-08-211-2/+2
| | | | | | | | | | | | | | | | | | | SystemZ builds show -Wframe-larger-than warnings in two functions: 'sanitizer::SuspendedThreadsListLinux::GetRegistersAndSP' 'sanitizer::SizeClassAllocator32<__sanitizer::AP32>::PopulateFreeList' In both cases, the frame size looks correct; each of the functions has a large local variable that brings the frame size close to the limit even on x86, and the extra 160 bytes of the default register save areas on SystemZ pushes it over the limit. PowerPC and MIPS already disable this warning; do the same on SystemZ. Differential Revision: https://reviews.llvm.org/D66021 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@369543 91177308-0d34-0410-b5e6-96231b3b80d8
* [CMake] Check for C++14 instead of C++11Jonas Devlieghere2019-08-151-1/+1
| | | | | | | | | | | | | | | Now that LLVM moved to C++14, `COMPILER_RT_HAS_STD_CXX11_FLAG` should become `COMPILER_RT_HAS_STD_CXX14_FLAG`. I ran into this issue when replacing llvm::make_unique with std::make_unique in an X-ray unit test. We are correctly passing `-std=c++14`, but this got overwritten further down the invocation by the compiler-rt flags. Given that this unit test is using LLVM headers, this is bound to break sooner than later, regardless of my change. Differential revision: https://reviews.llvm.org/D66271 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@368960 91177308-0d34-0410-b5e6-96231b3b80d8
* compiler-rt: Rename cc files below test/asan to cppNico Weber2019-08-051-1/+1
| | | | | | | See r367803 and similar other changes. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@367887 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove cmake checks for MSVC 1900 / VS 2013Reid Kleckner2019-07-301-6/+5
| | | | | | Our minimum Visual C++ version is 19.10 from Visual Studio 2017. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@367362 91177308-0d34-0410-b5e6-96231b3b80d8
* [CMake] Don't set Python_ADDITIONAL_VERSIONSJonas Devlieghere2019-07-181-1/+0
| | | | | | | | | | | | | | | | | | | | | | Until recently, Python_ADDITIONAL_VERSIONS was used to limit LLVM's Python support to 2.7. Now that both LLVM and LLDB both support Python 3, there's no longer a need to put an arbitrary limit on this. However, instead of removing the variable, r365692 expanded the list, which has the (presumably unintentional) side-effect of expression preference for Python 3. Instead, as Michal proposed in the original code review, we should just not set the list at all, and let CMake pick whatever Python interpreter you have in your path. This patch removes the Python_ADDITIONAL_VERSIONS variable in llvm, clang and lld. I've also updated the docs with the default behavior and how to force a different Python version to be used. Differential revision: https://reviews.llvm.org/D64894 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@366447 91177308-0d34-0410-b5e6-96231b3b80d8
* [compiler-rt][SystemZ] Work around ASAN failures via -fno-partial-inliningUlrich Weigand2019-06-181-0/+9
| | | | | | | | | | | | | | | | | | | Since updating the SystemZ LLVM build bot system to Ubuntu 18.04, all bots are red due to two ASAN failures. It turns out these are triggered due to building the ASAN support libraries, in particular the interceptor routines using GCC 7. Specifically, at least on our platform, this compiler decides to "partially inline" some of those interceptors, creating intermediate stub routines like "__interceptor_recvfrom.part.321". These will show up in the backtraces at interception points, causing testsuite failures. As a workaround to get the build bots green again, this patch adds the -fno-partial-inlining command line option when building the common sanitizer support libraries on s390x, if that option is supported by the compiler. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@363679 91177308-0d34-0410-b5e6-96231b3b80d8
* [builtins] Use libtool for builtins when building for Apple platformPetr Hosek2019-06-041-52/+2
| | | | | | | | | | | | compiler-rt already uses libtool instead of ar when building for Apple platform, but that's not being used when builtins are being built separately e.g. as part of the runtimes build. This change extracts the logic setting up libtool into a separate file and uses it from both the compiler-rt and standalone builtins build. Differential Revision: https://reviews.llvm.org/D62820 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@362466 91177308-0d34-0410-b5e6-96231b3b80d8
* [compiler-rt] Fix cmake warningsShoaib Meenai2019-05-281-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | - Fix cmake BOOL misspellings - Set cmake policy for CMP0075 to NEW As requested by smeenai I've compared CMAkeCache.txt in master with and without this patch and the only changes are to the variable types I fixed: $ diff build-b1-master/CMakeCache.txt build-b1-compiler-rt-fix-cmake-warnings/CMakeCache.txt 503c503 < COMPILER_RT_BAREMETAL_BUILD:STRING=OFF --- > COMPILER_RT_BAREMETAL_BUILD:BOOL=OFF 550c550 < COMPILER_RT_HWASAN_WITH_INTERCEPTORS:STRING=ON --- > COMPILER_RT_HWASAN_WITH_INTERCEPTORS:BOOL=ON Patch by Wink Saville <wink@saville.com>. Differential Revision: https://reviews.llvm.org/D61203 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@361866 91177308-0d34-0410-b5e6-96231b3b80d8
* [NFC][TSan][libdispatch] Tiny CMake file cleanupJulian Lettner2019-05-101-2/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@360453 91177308-0d34-0410-b5e6-96231b3b80d8
* Reland "[compiler-rt] Simple crtbegin.o and crtend.o implementation"Petr Hosek2019-04-301-0/+2
| | | | | | | | | | | | | | | Clang relies on existence of certain symbols that are normally provided by crtbegin.o/crtend.o. However, LLVM does not currently provide implementation of these files, instead relying on either libgcc or implementations provided as part of the system. This change provides an initial implementation of crtbegin.o/crtend.o that can be used on system that don't provide crtbegin.o/crtend.o as part of their C library. Differential Revision: https://reviews.llvm.org/D28791 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@359591 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[compiler-rt] Simple crtbegin.o and crtend.o implementation"Petr Hosek2019-04-301-2/+0
| | | | | | This reverts commit r359576 since it's failing on Windows bots. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@359579 91177308-0d34-0410-b5e6-96231b3b80d8
* [compiler-rt] Simple crtbegin.o and crtend.o implementationPetr Hosek2019-04-301-0/+2
| | | | | | | | | | | | | | | Clang relies on existence of certain symbols that are normally provided by crtbegin.o/crtend.o. However, LLVM does not currently provide implementation of these files, instead relying on either libgcc or implementations provided as part of the system. This change provides an initial implementation of crtbegin.o/crtend.o that can be used on system that don't provide crtbegin.o/crtend.o as part of their C library. Differential Revision: https://reviews.llvm.org/D28791 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@359576 91177308-0d34-0410-b5e6-96231b3b80d8
* [TSan][libdispatch] Specify libdispatch header dir for lit testsJulian Lettner2019-04-041-5/+7
| | | | | | | | | Specify libdispatch header dir (include path) for lit tests. This is the last missing piece in order to run the libdispatch tests on Linux even when libdispatch is installed in a custom path instead of a default (system) location. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@357707 91177308-0d34-0410-b5e6-96231b3b80d8
* [NFC][TSan][libdispatch] Better CMake variable namesJulian Lettner2019-04-041-4/+4
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@357664 91177308-0d34-0410-b5e6-96231b3b80d8
* [TSan][libdispatch] Add Cmake option for libdispatch install pathJulian Lettner2019-04-041-12/+5
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@357657 91177308-0d34-0410-b5e6-96231b3b80d8
* [TSan][libdispatch] We don't require any setup on DarwinJulian Lettner2019-04-021-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@357519 91177308-0d34-0410-b5e6-96231b3b80d8
* [TSan][libdispatch] Enable linking and running of tests on LinuxJulian Lettner2019-03-151-1/+20
| | | | | | | | | | | | | | | | | | | | | When COMPILER_RT_INTERCEPT_LIBDISPATCH is ON the TSan runtime library now has a dependency on the blocks runtime and libdispatch. Make sure we set all the required linking options. Also add cmake options for specifying additional library paths to instruct the linker where to search for libdispatch and the blocks runtime. This allows us to build TSan runtime with libdispatch support without installing those libraries into default linker library paths. `CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY` is necessary to avoid aborting the build due to failing the link step in CMake's check_c_compiler test. Reviewed By: dvyukov, kubamracek Differential Revision: https://reviews.llvm.org/D59334 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@356281 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sanitizer] Add 'dispatch' feature to be used in compiler-rt testsJulian Lettner2019-03-071-0/+1
| | | | | | | | Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D59037 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@355617 91177308-0d34-0410-b5e6-96231b3b80d8
* [tsan] Support interception of libdispatch on LinuxJulian Lettner2019-03-061-0/+6
| | | | | | | | | | | | | | | | | | | | | | | This is a new attempt for bringing TSan libdispatch support to Linux. The main issue with the last patch (https://reviews.llvm.org/D53171) was that we want to avoid building a separate library. The updated plan is as follows: 1) Hide libdispatch support behind a flag: true on Darwin, false elsewhere. If flag is specified, assume that libdispatch header and -flbocks is available for building. This way we can directly include the libdispatch header and rely on blocks runtime for our implementation. 2) Optionally/weakly intercept libdispatch API functions. This patch accomplishes 1). It compiles (without the flag enabled) on Linux. Follow-up patches will provide 2) and enabling of tests on Linux. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D58935 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@355538 91177308-0d34-0410-b5e6-96231b3b80d8
* [CMake] Don't use llvm_replace_compiler_optionMartin Storsjo2019-03-011-3/+7
| | | | | | | | | | | | | | Building compiler-rt standalone outside of the main llvm tree is supported, and in this case, the llvm cmake modules are unavailable. (And even if they are available, it requires including LLVMProcessSources.cmake, which currently isn't included.) This fixes building compiler-rt standalone with MSVC/clang-cl. Differential Revision: https://reviews.llvm.org/D58767 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@355237 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Build everything whereever possible with -z text.Evgeniy Stepanov2019-03-011-0/+1
| | | | | | | | | | | | Reviewers: pcc, phosek Subscribers: mgorny, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D58755 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@355164 91177308-0d34-0410-b5e6-96231b3b80d8
* [compiler-rt] Build custom libcxx with libcxxabiJonas Hahnfeld2019-02-171-0/+9
| | | | | | | | | | | | | | | This changes add_custom_libcxx to also build libcxxabi and merges the two into a static and hermetic library. There are multiple advantages: 1) The resulting libFuzzer doesn't expose C++ internals and looks like a plain C library. 2) We don't have to manually link in libstdc++ to provide cxxabi. 3) The sanitizer tests cannot interfere with an installed version of libc++.so in LD_LIBRARY_PATH. Differential Revision: https://reviews.llvm.org/D58013 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@354212 91177308-0d34-0410-b5e6-96231b3b80d8
* [compiler-rt] Cleanup usage of C++ ABI libraryJonas Hahnfeld2019-02-161-25/+47
| | | | | | | | | | | | | Add missed value "libcxxabi" and introduce SANITIZER_TEST_CXX for linking unit tests. This needs to be a full C++ library and cannot be libcxxabi. Recommit r354132 which I reverted in r354153 because it broke a sanitizer bot. This was because of the "fixes" for pthread linking, so I've removed these changes. Differential Revision: https://reviews.llvm.org/D58012 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@354198 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[compiler-rt] Cleanup usage of C++ ABI library"Jonas Hahnfeld2019-02-151-47/+25
| | | | | | | This reverts r354132 because it breaks sanitizer-x86_64-linux: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/19915 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@354153 91177308-0d34-0410-b5e6-96231b3b80d8
* [compiler-rt] Cleanup usage of C++ ABI libraryJonas Hahnfeld2019-02-151-25/+47
| | | | | | | | | Add missed value "libcxxabi" and introduce SANITIZER_TEST_CXX for linking unit tests. This needs to be a full C++ library and cannot be libcxxabi. Differential Revision: https://reviews.llvm.org/D58012 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@354132 91177308-0d34-0410-b5e6-96231b3b80d8
* gn build: Upgrade to NDK r19.Peter Collingbourne2019-02-051-0/+3
| | | | | | | | | | NDK r19 includes a sysroot that can be used directly by the compiler without creating a standalone toolchain, so we just need a handful of flags to point Clang there. Differential Revision: https://reviews.llvm.org/D57733 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@353139 91177308-0d34-0410-b5e6-96231b3b80d8
* [CMake][compiler-rt] Enable statically linking unwinder and c++abiPetr Hosek2019-01-311-6/+25
| | | | | | | | | | Rather than guessing whether to use static or shared version of unwinder and c++abi when using linking against the in-tree versions, provide a CMake option to control this. Differential Revision: https://reviews.llvm.org/D57492 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@352723 91177308-0d34-0410-b5e6-96231b3b80d8
* [compiler-rt] Add option to disable libc++ buildShoaib Meenai2019-01-141-9/+13
| | | | | | | | | | | | | Having libc++ checked out doesn't necessarily mean it should be built; for example, the same source tree might be used for multiple build configurations, and libc++ might not build in some of those configurations. Add an option to compiler-rt's build to disable building libc++. This defaults to ON, so it shouldn't change any existing build configurations. Differential Revision: https://reviews.llvm.org/D56479 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@351117 91177308-0d34-0410-b5e6-96231b3b80d8
* Set the default SANITIZER_CXX_ABI library to libc++ for FreeBSD, andDimitry Andric2018-12-231-1/+1
| | | | | | | also mark it as a system library, like on macOS. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@350020 91177308-0d34-0410-b5e6-96231b3b80d8
* [CMake] When built with LLVM, not use `-Wl,-z,defs`Petr Hosek2018-10-291-0/+1
| | | | | | | | | | This matches standalone build behavior. PR28681 Differential Revision: https://reviews.llvm.org/D53686 Patch By: tabloid.adroit git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@345547 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Use -Wl,-z,global on Android for sanitizers except UBsanStephen Hines2018-10-021-8/+0
| | | | | | | | | | | | | | | | | | Summary: This essentially reverts r337010 since it breaks UBSan, which is used for a few platform libraries. The "-z global" flag is now added for Scudo as well. The only other sanitizer shared libraries are for asan and hwasan, which have also been reinstated to use the global flag. Reviewers: cryptoad, eugenis Reviewed By: cryptoad Subscribers: kubamracek, mgorny, delcypher, #sanitizers, nickdesaulniers, chh, kongyi, pirama, llvm-commits Differential Revision: https://reviews.llvm.org/D52770 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@343599 91177308-0d34-0410-b5e6-96231b3b80d8
* [CMake] [MinGW] Build address sanitizer for MinGW if building with clangMartin Storsjo2018-09-261-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D51885 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@343074 91177308-0d34-0410-b5e6-96231b3b80d8
* build: clean up some unnecessary cached variablesSaleem Abdulrasool2018-09-181-5/+0
| | | | | | | | | The CMAKE_<LANG>_ARCHIVE_FINISH rule doesn't need to be cleared for Darwin static libraries. Avoid resetting the variables in the SIP case. If CMAKE_RANLIB is cached, then CMake's Ninja generator will invoke ranlib during installation, not due to the CMAKE_<LANG>_ARCHIVE_FINISH rule. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@342511 91177308-0d34-0410-b5e6-96231b3b80d8
* build: fix standalone builds for compiler-rt on DarwinSaleem Abdulrasool2018-09-171-0/+60
| | | | | | | | | | | When building static fat libraries, we need to ensure that we use libtool rather than llvm-ar to create the library. Duplicate the rules from LLVM to ensure that we correctly build the fat libraries when building compiler-rt standalone. This also requires that we duplicate the workaround for the `DYLD_LIBRARY_PATH` for SIP. Additionally, ensure that we set the `CMAKE_*_ARCHIVE_FINISH` variable to ensure that we do not try to use `ranlib` on that target. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@342425 91177308-0d34-0410-b5e6-96231b3b80d8
* [hwasan] Add a (almost) no-interceptor mode.Evgeniy Stepanov2018-08-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The idea behind this change is to allow sanitization of libc. We are prototyping on Bionic, but the tool interface will be general enough (or at least generalizable) to support any other libc. When libc depends on libclang_rt.hwasan, the latter can not interpose libc functions. In fact, majority of interceptors become unnecessary when libc code is instrumented. This change gets rid of most hwasan interceptors and provides interface for libc to notify hwasan about thread creation and destruction events. Some interceptors (pthread_create) are kept under #ifdef to enable testing with uninstrumented libc. They are expressed in terms of the new libc interface. The new cmake switch, COMPILER_RT_HWASAN_WITH_INTERCEPTORS, ON by default, builds testing version of the library with the aforementioned pthread_create interceptor. With the OFF setting, the library becomes more of a libc plugin. Reviewers: vitalybuka, kcc, jfb Subscribers: srhines, kubamracek, mgorny, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D50922 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@340216 91177308-0d34-0410-b5e6-96231b3b80d8
* [CMake] Don't parse target triple except for archPetr Hosek2018-08-141-2/+2
| | | | | | | | | | | | | | compiler-rt CMake build currently tries to parse the triple and then put it back together, but doing so inherently tricky, and doing so from CMake is just crazy and currently doesn't handle triples that have more than three components. Fortunatelly, the CMake really only needs the architecture part, which is typically the first component, to construct variants for other architectures. This means we can keep the rest of the triple as is and avoid the parsing altogether. Differential Revision: https://reviews.llvm.org/D50548 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@339701 91177308-0d34-0410-b5e6-96231b3b80d8
* [CMake] Change the flag to use compiler-rt builtins to booleanPetr Hosek2018-07-151-10/+7
| | | | | | | | | | | | This changes the name and the type to what it was prior to r333037 which matches the name of the flag used in other runtimes: libc++, libc++abi and libunwind. We don't need the type to be a string since there's only binary choice between libgcc and compiler-rt unlike in the case of C++ library where there're multiple options. Differential Revision: https://reviews.llvm.org/D49325 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@337116 91177308-0d34-0410-b5e6-96231b3b80d8
* [CMake] Don't use CLANG_DEFAULT_* valuesPetr Hosek2018-07-131-7/+2
| | | | | | | | | | | | | | These are not necessarily correct, just because Clang is configured to use libc++ or compiler-rt as defaults doesn't mean that the host compiler uses these as defaults as well. A more correct solution would be to test the host compiler to check what the default actually is as attempted in D46857. Part of PR-38025. Differential Revision: https://reviews.llvm.org/D49272 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@337033 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Use -Wl,-z,global on AndroidKostya Kortchinsky2018-07-131-0/+8
| | | | | | | | | | | | | | | | | | | | | | | Summary: Use `-Wl,-z,global` for all Sanitizer shared libraries on Android. We want them to be in the global group (https://android.googlesource.com/platform/bionic/+/master/android-changes-for-ndk-developers.md#changes-to-library-search-order) to avoid any alloc/dealloc mismatch between the libc allocator & said library. `audioserver` was one of the binary that exhibited the problem with Scudo, this seems to fix it. [edited for accuracy] Reviewers: eugenis, alekseyshl Reviewed By: eugenis Subscribers: kubamracek, srhines, mgorny, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D49198 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@337010 91177308-0d34-0410-b5e6-96231b3b80d8
* Add libcxxabi option back for sanitizer use.Stephen Hines2018-07-111-0/+2
| | | | | | | | | | | | | | | | | | Summary: A prior refactoring accidentally dropped the case for using libc++abi as the out-of-tree C++ runtime library for sanitizers. This patch restores that functionality, which is used by Android, which can't depend on the full libc++ for these libraries. Reviewers: phosek, EricWF Reviewed By: phosek Subscribers: meikeb, kongyi, chh, mgorny, delcypher, llvm-commits, #sanitizers, pirama Differential Revision: https://reviews.llvm.org/D49157 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@336749 91177308-0d34-0410-b5e6-96231b3b80d8
* Support for multiarch runtimes layoutPetr Hosek2018-06-281-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@335809 91177308-0d34-0410-b5e6-96231b3b80d8
* [CMake] Tidy up the organisation of compiler-rt when configured as a standaloneDan Liew2018-06-271-0/+6
| | | | | | | | | | | | | | | | | | | build with an IDE (e.g. Xcode) as the generator. Previously the global `USE_FOLDERS` property wasn't set in standalone builds leading to existing settings of FOLDER not being respected. In addition to this there were several targets that appeared at the top level that were not interesting and clustered up the view. These have been changed to be displayed in "Compiler-RT Misc". Now when an Xcode project is generated from a standalone compiler-rt build the project navigator is much less cluttered. The interesting libraries should appear in "Compiler-RT Libraries" in the IDE. Differential Revision: https://reviews.llvm.org/D48378 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@335728 91177308-0d34-0410-b5e6-96231b3b80d8
* [CMake] Support builtins as Clang default rtlib in compiler-rtPetr Hosek2018-05-221-5/+13
| | | | | | | | | | | | | Use compiler-rt builtins when selected as default Clang rtlib and avoid explicitly passing -rtlib= flag to avoid the "argument unused during compilation" warning. This is a partial alternative to D47094 that does not rely on compiler runtime checks. Differential Revision: https://reviews.llvm.org/D47115 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@333037 91177308-0d34-0410-b5e6-96231b3b80d8
* [CMake] Support libc++ as Clang default stdlib in compiler-rtPetr Hosek2018-05-221-28/+31
| | | | | | | | | | | | Use libc++ when selected as default Clang stdlib and avoid checking C++ compiler when using the in-tree version of libc++. This is a partial alternative to D47094 that does not rely on compiler runtime checks. Differential Revision: https://reviews.llvm.org/D47100 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@333010 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[CMake] Reland "Make simple source used for CMake checks a C file""Petr Hosek2018-05-211-1/+0
| | | | | | | This reverts commit rCRT332679 which doesn't quite work and will be replaced by D47100 and D47115 which is a cleaner solution. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@332871 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r332683 & r332684 relating to compiler runtime checksReid Kleckner2018-05-181-27/+29
| | | | | | | r332683 passes flags to the compiler without first checking if they are supported. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@332754 91177308-0d34-0410-b5e6-96231b3b80d8
* [CMake] Detect the compiler runtime and standard libraryPetr Hosek2018-05-181-29/+27
| | | | | | | | | | Rather then requiring the user to specify runtime the compiler runtime and C++ standard library, or trying to guess them which is error-prone, use auto-detection by parsing the compiler link output. Differential Revision: https://reviews.llvm.org/D46857 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@332683 91177308-0d34-0410-b5e6-96231b3b80d8
* [CMake] Reland "Make simple source used for CMake checks a C file"Petr Hosek2018-05-171-0/+1
| | | | | | | | | | | The source being compiled is plain C, but using .cc extension forces it to be compiled as C++ which requires a working C++ compiler including C++ library which may not be the case when we're building compiler-rt together with libcxx as part of runtimes build. Differential Revision: https://reviews.llvm.org/D47031 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@332679 91177308-0d34-0410-b5e6-96231b3b80d8
View Lorry Controller Status