aboutsummaryrefslogtreecommitdiff
path: root/cmake
AgeCommit message (Collapse)Author
2019-07-12Enable compiler-rt on SPARCRainer Orth
This patch enables compiler-rt on SPARC targets. Most of the changes are straightforward: - Add 32 and 64-bit sparc to compiler-rt - lib/builtins/fp_lib.h needed to check if the int128_t and uint128_t types exist (which they don't on sparc) There's one issue of note: many asan tests fail to compile on Solaris/SPARC: fatal error: error in backend: Function "_ZN7testing8internal16BoolFromGTestEnvEPKcb": over-aligned dynamic alloca not supported. Therefore, while asan is still built, both asan and ubsan-with-asan testing is disabled. The goal is to check if asan keeps compiling on Solaris/SPARC. This serves asan in gcc, which doesn't have the problem above and works just fine. With this patch, sparcv9-sun-solaris2.11 test results are pretty good: Failing Tests (9): Builtins-sparc-sunos :: divtc3_test.c Builtins-sparcv9-sunos :: compiler_rt_logbl_test.c Builtins-sparcv9-sunos :: divtc3_test.c [...] UBSan-Standalone-sparc :: TestCases/TypeCheck/misaligned.cpp UBSan-Standalone-sparcv9 :: TestCases/TypeCheck/misaligned.cpp The builtin failures are due to Bugs 42493 and 42496. The tree contained a few additonal patches either currently in review or about to be submitted. Tested on sparcv9-sun-solaris2.11. Differential Revision: https://reviews.llvm.org/D40943 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@365880 91177308-0d34-0410-b5e6-96231b3b80d8
2019-07-11Add NetBSD LSan supportKamil Rytarowski
Summary: Combine few relatively small changes into one: - implement internal_ptrace() and internal_clone() for NetBSD - add support for stoptheworld based on the ptrace(2) API - define COMPILER_RT_HAS_LSAN for NetBSD - enable tests for NetBSD/amd64 Inspired by the original implementation by Christos Zoulas in netbsd/src for GCC. The implementation is in theory CPU independent through well defined macros across all NetBSD ports, however only the x86_64 version was tested. Reviewers: mgorny, dvyukov, vitalybuka, joerg, jfb Reviewed By: vitalybuka Subscribers: dexonsmith, jfb, srhines, kubamracek, llvm-commits, christos Tags: #llvm Differential Revision: https://reviews.llvm.org/D64057 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@365735 91177308-0d34-0410-b5e6-96231b3b80d8
2019-06-26[GWP-ASan] D63736 broke ARMv7/v8 sanitizer bots.Mitch Phillips
Remove ARM32/ARM64 support for GWP-ASan due to a strange SEGV when running scudo's preinit.c test. Disabling to make the bots go green while investigating. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@364486 91177308-0d34-0410-b5e6-96231b3b80d8
2019-06-19Specify log level for CMake messages (less stderr)Stefan Granitz
Summary: Specify message levels in CMake. Prefer STATUS (stdout). As the default message mode (i.e. level) is NOTICE in CMake, more then necessary messages get printed to stderr. Some tools, noticably ccmake treat this as an error and require additional confirmation and re-running CMake's configuration step. This commit specifies a mode (either STATUS or WARNING or FATAL_ERROR) instead of the default. * I used `csearch -f 'llvm-project/.+(CMakeLists\.txt|cmake)' -l 'message\("'` to find all locations. * Reviewers were chosen by the most common authors of specific files. If there are more suitable reviewers for these CMake changes, please let me know. Patch by: Christoph Siedentop Reviewers: zturner, beanz, xiaobai, kbobyrev, lebedev.ri, sgraenitz Reviewed By: sgraenitz Subscribers: mgorny, lebedev.ri, #sanitizers, lldb-commits, llvm-commits Tags: #sanitizers, #lldb, #llvm Differential Revision: https://reviews.llvm.org/D63370 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@363821 91177308-0d34-0410-b5e6-96231b3b80d8
2019-06-19Revert r363633 "[CMake] Fix the value of `config.target_cflags` for ↵Hans Wennborg
non-macOS Apple platforms. Attempt #2." This caused Chromium's clang package to stop building, see comment on https://reviews.llvm.org/D61242 for details. > Summary: > The main problem here is that `-*-version_min=` was not being passed to > the compiler when building test cases. This can cause problems when > testing on devices running older OSs because Clang would previously > assume the minimum deployment target is the the latest OS in the SDK > which could be much newer than what the device is running. > > Previously the generated value looked like this: > > `-arch arm64 -isysroot > <path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk` > > With this change it now looks like: > > `-arch arm64 -stdlib=libc++ -miphoneos-version-min=8.0 -isysroot > <path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk` > > This mirrors the setting of `config.target_cflags` on macOS. > > This change is made for ASan, LibFuzzer, TSan, and UBSan. > > To implement this a new `get_test_cflags_for_apple_platform()` function > has been added that when given an Apple platform name and architecture > returns a string containing the C compiler flags to use when building > tests. This also calls a new helper function `is_valid_apple_platform()` > that validates Apple platform names. > > This is the second attempt at landing the patch. The first attempt (r359305) > had to be reverted (r359327) due to a buildbot failure. The problem was > that calling `get_test_cflags_for_apple_platform()` can trigger a CMake > error if the provided architecture is not supported by the current > CMake configuration. Previously, this could be triggered by passing > `-DCOMPILER_RT_ENABLE_IOS=OFF` to CMake. The root cause is that we were > generating test configurations for a list of architectures without > checking if the relevant Sanitizer actually supported that architecture. > We now intersect the list of architectures for an Apple platform > with `<SANITIZER>_SUPPORTED_ARCH` (where `<SANITIZER>` is a Sanitizer > name) to iterate through the correct list of architectures. > > rdar://problem/50124489 > > Reviewers: kubamracek, yln, vsk, juliehockett, phosek > > Subscribers: mgorny, javed.absar, kristof.beyls, #sanitizers, llvm-commits > > Tags: #llvm, #sanitizers > > Differential Revision: https://reviews.llvm.org/D61242 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@363779 91177308-0d34-0410-b5e6-96231b3b80d8
2019-06-18[compiler-rt][SystemZ] Work around ASAN failures via -fno-partial-inliningUlrich Weigand
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
2019-06-17[CMake] Fix the value of `config.target_cflags` for non-macOS Apple ↵Dan Liew
platforms. Attempt #2. Summary: The main problem here is that `-*-version_min=` was not being passed to the compiler when building test cases. This can cause problems when testing on devices running older OSs because Clang would previously assume the minimum deployment target is the the latest OS in the SDK which could be much newer than what the device is running. Previously the generated value looked like this: `-arch arm64 -isysroot <path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk` With this change it now looks like: `-arch arm64 -stdlib=libc++ -miphoneos-version-min=8.0 -isysroot <path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk` This mirrors the setting of `config.target_cflags` on macOS. This change is made for ASan, LibFuzzer, TSan, and UBSan. To implement this a new `get_test_cflags_for_apple_platform()` function has been added that when given an Apple platform name and architecture returns a string containing the C compiler flags to use when building tests. This also calls a new helper function `is_valid_apple_platform()` that validates Apple platform names. This is the second attempt at landing the patch. The first attempt (r359305) had to be reverted (r359327) due to a buildbot failure. The problem was that calling `get_test_cflags_for_apple_platform()` can trigger a CMake error if the provided architecture is not supported by the current CMake configuration. Previously, this could be triggered by passing `-DCOMPILER_RT_ENABLE_IOS=OFF` to CMake. The root cause is that we were generating test configurations for a list of architectures without checking if the relevant Sanitizer actually supported that architecture. We now intersect the list of architectures for an Apple platform with `<SANITIZER>_SUPPORTED_ARCH` (where `<SANITIZER>` is a Sanitizer name) to iterate through the correct list of architectures. rdar://problem/50124489 Reviewers: kubamracek, yln, vsk, juliehockett, phosek Subscribers: mgorny, javed.absar, kristof.beyls, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D61242 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@363633 91177308-0d34-0410-b5e6-96231b3b80d8
2019-06-17[GWP-ASan] Disable GWP-ASan on Android for now.Mitch Phillips
Summary: Temporarily disable GWP-ASan for android until the bugs at: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-android/builds/87 ... can be fixed. See comments for the full bug trace. Reviewers: eugenis Reviewed By: eugenis Subscribers: srhines, kubamracek, mgorny, cryptoad, jfb, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D63460 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@363624 91177308-0d34-0410-b5e6-96231b3b80d8
2019-06-15[compiler-rt] Respect CMAKE_NMShoaib Meenai
The default nm executable may not be able to handle the architecture we're building the sanitizers for. Respect CMAKE_NM if it's set to ensure we're using the correct nm tool. Preserve the existing NM environment variable override to not break its users. Differential Revision: https://reviews.llvm.org/D63368 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@363483 91177308-0d34-0410-b5e6-96231b3b80d8
2019-06-04Fixed GWP-ASan build breakage. When adding the optional flag parser, there ↵Mitch Phillips
was a missing dependency on compiler-rt (and thus SanitizerCommon) for this feature. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@362542 91177308-0d34-0410-b5e6-96231b3b80d8
2019-06-04[builtins] Use libtool for builtins when building for Apple platformPetr Hosek
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
2019-05-27[Driver] Change layout of per-target runtimes to resemble multiarchPetr Hosek
This is a follow up to r361432, changing the layout of per-target runtimes to more closely resemble multiarch. While before, we used the following layout: [RESOURCE_DIR]/<target>/lib/libclang_rt.<runtime>.<ext> Now we use the following layout: [RESOURCE_DIR]/lib/<target>/libclang_rt.<runtime>.<ext> This also more closely resembles the existing "non-per-target" layout: [RESOURCE_DIR]/lib/<os>/libclang_rt.<runtime>-<arch>.<ext> This change will enable further simplification of the driver logic in follow up changes. Differential Revision: https://reviews.llvm.org/D62469 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@361784 91177308-0d34-0410-b5e6-96231b3b80d8
2019-05-19Use CMAKE_C_COMPILER_ARG1 in compiler invocationPetr Hosek
This is needed when using compiler wrappers such as ccache or distcc and should address the failure on clang-x86_64-debian-fast bot. Differential Revision: https://reviews.llvm.org/D62104 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@361111 91177308-0d34-0410-b5e6-96231b3b80d8
2019-05-15[mips] Always use _LARGEFILE_SOURCE / _FILE_OFFSET_BITS for building MIPS 32-bitSimon Atanasyan
When MIPS 32-bit compiler-rt is building on 32-bit host or using 32-bit `DLLVM_HOST_TRIPLE` the `_LARGEFILE_SOURCE` and the `_FILE_OFFSET_BITS=64` macros defined by statements from the `HandleLLVMOptions.cmake`. In case of building 32-bit libraries on 64-bit host using default host triple these macros are not defined. As a result assertions check a consistency between the `struct_kernel_stat_sz` constant and the `struct_kernel_stat_sz` start to fail. To resolve this problem and enable building both 32/64-bit versions of MIPS compiler-rt libraries on 64-bit host at once always explicitly define the `_LARGEFILE_SOURCE` and the `_FILE_OFFSET_BITS=64` macros for MIPS 32-bit. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@360825 91177308-0d34-0410-b5e6-96231b3b80d8
2019-05-14[GWP-ASan] Initial build files, implementation of PRNG [1].Mitch Phillips
Summary: See D60593 for further information. This patch slices off the PRNG implementation and the initial build files for GWP-ASan. Reviewers: vlad.tsyrklevich, morehouse, vitalybuka Reviewed By: morehouse Subscribers: srhines, kubamracek, mgorny, #sanitizers, llvm-commits, cryptoad, eugenis Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D61867 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@360710 91177308-0d34-0410-b5e6-96231b3b80d8
2019-05-10[crt] Use -std=c11 for crtbegin.o/crtend.oPetr Hosek
The source uses C11 syntax such as comments and some compilers print warnings without specifying this flag. Differential Revision: https://reviews.llvm.org/D61797 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@360459 91177308-0d34-0410-b5e6-96231b3b80d8
2019-05-07[compiler-rt] Create install targets for Darwin librariesShoaib Meenai
Darwin targets were generating CMake install rules but not the corresponding install targets. Centralize the existing install target creation to a function and use that function for both Darwin and non-Darwin builds. Differential Revision: https://reviews.llvm.org/D61541 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@360181 91177308-0d34-0410-b5e6-96231b3b80d8
2019-05-03[Lsan] Disabling explicitally FreeBSDDavid Carlier
As it is not implemented upon usage, it just provokes numerous linkage issues so better switch off clearly. Reviewers: vitalybuka, morehouse Reviewed By: morehouse Differential Revision: https://reviews.llvm.org/D61484 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@359920 91177308-0d34-0410-b5e6-96231b3b80d8
2019-05-02[libFuzzer] Re-enable libFuzzer on i386 Linux and fix testJonathan Metzman
Summary: Re-enable libFuzzer on i386 Linux after it was accidentally disabled. Also disable gc-sections.test on i386 since lld isn't garbage collecting properly with ASAN on i386. Reviewers: morehouse Reviewed By: morehouse Subscribers: srhines, mgorny, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D61415 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@359802 91177308-0d34-0410-b5e6-96231b3b80d8
2019-05-01[compiler-rt] Cleanup the --target and --sysroot handlingPetr Hosek
This addresses issue introduced in r359646. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@359650 91177308-0d34-0410-b5e6-96231b3b80d8
2019-05-01[compiler-rt] Pass sysroot and disable pedantic for crtbegin.o/crtend.oPetr Hosek
These are needed to make bots happy. Differential Revision: https://reviews.llvm.org/D61363 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@359646 91177308-0d34-0410-b5e6-96231b3b80d8
2019-05-01[compiler-rt] Rework the object build supportPetr Hosek
The initial implementation didn't properly support cross-compilation via the runtime build, the updated implementation should address that by expanding the CMAKE_C_COMPILE_OBJECT variable with correct values. Differential Revision: https://reviews.llvm.org/D61356 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@359644 91177308-0d34-0410-b5e6-96231b3b80d8
2019-05-01[libFuzzer] Disable i386 on non-Linux platformsJonathan Metzman
Summary: Disable i386 on non-Linux platforms since it is unwanted and broken on Windows. Reviewers: morehouse, rnk Reviewed By: morehouse Subscribers: mgorny, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D61354 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@359641 91177308-0d34-0410-b5e6-96231b3b80d8
2019-04-30Reland "[compiler-rt] Simple crtbegin.o and crtend.o implementation"Petr Hosek
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
2019-04-30Enable x86 buildsJonathan Metzman
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@359583 91177308-0d34-0410-b5e6-96231b3b80d8
2019-04-30Revert "[compiler-rt] Simple crtbegin.o and crtend.o implementation"Petr Hosek
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
2019-04-30[compiler-rt] Simple crtbegin.o and crtend.o implementationPetr Hosek
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
2019-04-26Revert "[CMake] Fix the value of `config.target_cflags` for non-macOS Apple"Dan Liew
This reverts commit 1bcdbd68616dc7f8debe126caafef7a7242a0e6b. It's been reported that some bots are failing with this change with CMake error like: ``` CMake Error at /b/s/w/ir/k/llvm-project/compiler-rt/cmake/config-ix.cmake:177 (message): Unsupported architecture: arm64 Call Stack (most recent call first): /b/s/w/ir/k/llvm-project/compiler-rt/cmake/config-ix.cmake:216 (get_target_flags_for_arch) /b/s/w/ir/k/llvm-project/compiler-rt/test/tsan/CMakeLists.txt:78 (get_test_cflags_for_apple_platform) ``` I'm reverting the patch now to unbreak builds. I will investigate properly when time permits. rdar://problem/50124489 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@359327 91177308-0d34-0410-b5e6-96231b3b80d8
2019-04-26[CMake] Fix the value of `config.target_cflags` for non-macOS AppleDan Liew
platforms. The main problem here is that `-*-version_min=` was not being passed to the compiler when building test cases. This can cause problems when testing on devices running older OSs because Clang would previously assume the minimum deployment target is the the latest OS in the SDK which could be much newer than what the device is running. Previously the generated value looked like this: `-arch arm64 -isysroot <path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk` With this change it now looks like: `-arch arm64 -stdlib=libc++ -miphoneos-version-min=8.0 -isysroot <path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk` This mirrors the setting of `config.target_cflags` on macOS. This change is made for ASan, LibFuzzer, TSan, and UBSan. To implement this a new `get_test_cflags_for_apple_platform()` function has been added that when given an Apple platform name and architecture returns a string containing the C compiler flags to use when building tests. This also calls a new helper function `is_valid_apple_platform()` that validates Apple platform names. rdar://problem/50124489 Differential Revision: https://reviews.llvm.org/D58578 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@359305 91177308-0d34-0410-b5e6-96231b3b80d8
2019-04-25[compiler-rt] Build custom libc++abi without exceptions.Matt Morehouse
Summary: Since neither compiler-rt nor the libc++ we build use exceptions, we don't need libc++abi to have them either. This resolves an issue where libFuzzer's private libc++ contains implementations for __cxa_throw and friends, causing fuzz targets built with their own C++ library to segfault during exception unwinding. See https://github.com/google/oss-fuzz/issues/2328. Reviewers: phosek, EricWF, kcc Reviewed By: phosek Subscribers: kcc, dberris, mgorny, christof, llvm-commits, metzman Tags: #llvm Differential Revision: https://reviews.llvm.org/D61053 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@359218 91177308-0d34-0410-b5e6-96231b3b80d8
2019-03-30[cmake] Change deprecated $<CONFIG> to $<CONFIGURATION>. NFCFangrui Song
See rL357338 for a similar change. The informational expression $<CONFIGURATION> has been deprecated since CMake 3.0 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@357348 91177308-0d34-0410-b5e6-96231b3b80d8
2019-03-15[CMake] Fix broken uses of `try_compile_only()` and improve the function.Dan Liew
Summary: There were existing calls to `try_compile_only()` with arguments not prefixed by `SOURCE` or `FLAGS`. These were silently being ignored. It looks like the `SOURCE` and `FLAGS` arguments were first introduced in r278454. One implication of this is that for a builtins only build for Darwin (see `darwin_test_archs()`) it would mean we weren't actually passing `-arch <arch>` to the compiler). This would result in compiler-rt claiming all supplied architectures could be targetted provided the compiler could build for Clang's default architecture. This patch fixes this in several ways. * Fixes all incorrect calls to `try_compile_only()`. * Adds code to `try_compile_only()` to check for unhandled arguments and raises a fatal error if this occurs. This should stop any incorrect calls in the future. * Improve the documentation on `try_compile_only()` which seemed completely wrong. rdar://problem/48928526 Reviewers: beanz, fjricci, dsanders, kubamracek, yln, dcoughlin Subscribers: mgorny, jdoerfert, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D59429 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@356295 91177308-0d34-0410-b5e6-96231b3b80d8
2019-03-15[TSan][libdispatch] Enable linking and running of tests on LinuxJulian Lettner
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
2019-03-11Remove esan.Nico Weber
It hasn't seen active development in years, and it hasn't reached a state where it was useful. Remove the code until someone is interested in working on it again. Differential Revision: https://reviews.llvm.org/D59133 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@355862 91177308-0d34-0410-b5e6-96231b3b80d8
2019-03-07Delete x86_64 ShadowCallStack supportVlad Tsyrklevich
Summary: ShadowCallStack on x86_64 suffered from the same racy security issues as Return Flow Guard and had performance overhead as high as 13% depending on the benchmark. x86_64 ShadowCallStack was always an experimental feature and never shipped a runtime required to support it, as such there are no expected downstream users. Reviewers: pcc Reviewed By: pcc Subscribers: mgorny, javed.absar, hiraditya, jdoerfert, cfe-commits, #sanitizers, llvm-commits Tags: #clang, #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D59034 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@355624 91177308-0d34-0410-b5e6-96231b3b80d8
2019-03-01[sanitizer] Build everything whereever possible with -z text.Evgeniy Stepanov
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
2019-02-19[compiler-rt][CMake] Set project for the custom libc++Petr Hosek
This is another follow up to r354212 which is broken on Darwin when cross-compiling runtimes to Linux when it ignores the -fuse-ld=lld linker flag and attempts to use the host linker when performing the compiler identification. Upon investigation, I noticed that setting the project with appropriate list of languages makes the error go away and it shouldn't hurt either. Differential Revision: https://reviews.llvm.org/D58372 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@354350 91177308-0d34-0410-b5e6-96231b3b80d8
2019-02-17[compiler-rt] Build custom libcxx with libcxxabiJonas Hahnfeld
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
2019-02-15Revert "[compiler-rt] Cleanup usage of C++ ABI library"Jonas Hahnfeld
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
2019-02-15[compiler-rt] Let CMake search for thread supportJonas Hahnfeld
This is an educated guess to fix sanitizer-x86_64-linux after r354132. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@354143 91177308-0d34-0410-b5e6-96231b3b80d8
2019-02-13[CMake] Avoid clang dependencies in the runtimes buildPetr Hosek
Dependencies like clang aren't available in the runtimes build, this was accidentally omitted in D57992. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@353914 91177308-0d34-0410-b5e6-96231b3b80d8
2019-02-12[CMake][XRay] Silence llvm-config error when checking library supportPetr Hosek
Otherwise this propagates all the way to CMake and results in an error during configuration. We check and handle the result and report warning separately so this is not changing the behavior. Differential Revision: https://reviews.llvm.org/D58086 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@353784 91177308-0d34-0410-b5e6-96231b3b80d8
2019-02-09[CMake] Don't set <PROJECT>_STANDALONE_BUILDPetr Hosek
We shouldn't be treating runtimes builds as standalone builds since we have enough of the context loaded into the runtimes environment. Differential Revision: https://reviews.llvm.org/D57992 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@353601 91177308-0d34-0410-b5e6-96231b3b80d8
2019-02-08[InstrProf] Implement static profdata registrationReid Kleckner
Summary: The motivating use case is eliminating duplicate profile data registered for the same inline function in two object files. Before this change, users would observe multiple symbol definition errors with VC link, but links with LLD would succeed. Users (Mozilla) have reported that PGO works well with clang-cl and LLD, but when using LLD without this static registration, we would get into a "relocation against a discarded section" situation. I'm not sure what happens in that situation, but I suspect that duplicate, unused profile information was retained. If so, this change will reduce the size of such binaries with LLD. Now, Windows uses static registration and is in line with all the other platforms. Reviewers: davidxl, wmi, inglorion, void, calixte Subscribers: mgorny, krytarowski, eraman, fedor.sergeev, hiraditya, #sanitizers, dmajor, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D57929 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@353547 91177308-0d34-0410-b5e6-96231b3b80d8
2019-02-08[scudo][standalone] Correct cmake copy/paste errorKostya Kortchinsky
Summary: I mistakenly used a SCUDO variable instead of SCUDO_STANDALONE one. The net result was that there were more architecture supported than I intended. Correct that, I'll add more architectures once the bots are enabled and green for x86. Reviewers: eugenis, vitalybuka Reviewed By: vitalybuka Subscribers: mgorny, delcypher, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D57897 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@353528 91177308-0d34-0410-b5e6-96231b3b80d8
2019-02-07[CMake] Mark runtime library link libraries as privatePetr Hosek
There's no need to expose these dependencies to consumers. This matches the change made to other runtimes in D57456. Differential Revision: https://reviews.llvm.org/D57873 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@353376 91177308-0d34-0410-b5e6-96231b3b80d8
2019-02-04[scudo] Initial standalone skeleton check-inKostya Kortchinsky
Summary: This is the initial check-in for the Standalone version of Scudo. The project is initially going to live in scudo/standalone then will replace scudo. See http://lists.llvm.org/pipermail/llvm-dev/2019-January/129113.html for details. This initial CL is meant to lay out the project structure, of both code & tests, providing a minimal amount of functionalities, namely various definitions, some atomic helpers and an intrusive list. (empty.cc is just here to have a compilation unit, but will go away in the upcoming CLs). Initial support is restricted to Linux i386 & x86_64 in make files and will be extended once things land & work. We will grow organically from here, adding functionalities in limited amounts. Reviewers: morehouse, eugenis, vitalybuka, kcc, mcgrathr, flowerhack Reviewed By: morehouse, vitalybuka Subscribers: srhines, mgorny, krytarowski, delcypher, jfb, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D57412 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@353055 91177308-0d34-0410-b5e6-96231b3b80d8
2019-01-28Revert "[CMake] Use __libc_start_main rather than fopen when checking for C ↵Petr Hosek
library" This reverts commit r352341: it broke the build on macOS which doesn't seem to provide __libc_start_main in its C library. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@352411 91177308-0d34-0410-b5e6-96231b3b80d8
2019-01-28[CMake] Use __libc_start_main rather than fopen when checking for C libraryPetr Hosek
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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@352341 91177308-0d34-0410-b5e6-96231b3b80d8
2019-01-25Fix XRayTest link on FreeBSD (and likely NetBSD too)Dimitry Andric
Summary: As reported on llvm-testers, during 8.0.0-rc1 testing I got errors while building of `XRayTest`, during `check-all`: ``` [100%] Generating XRayTest-x86_64-Test /home/dim/llvm/8.0.0/rc1/Phase3/Release/llvmCore-8.0.0-rc1.obj/./lib/libLLVMSupport.a(Signals.cpp.o): In function `llvm::sys::PrintStackTrace(llvm::raw_ostream&)': Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x24): undefined reference to `backtrace' Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x254): undefined reference to `llvm::itaniumDemangle(char const*, char*, unsigned long*, int*)' clang-8: error: linker command failed with exit code 1 (use -v to see invocation) gmake[3]: *** [projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build.make:73: projects/compiler-rt/lib/xray/tests/unit/XRayTest-x86_64-Test] Error 1 gmake[3]: Target 'projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build' not remade because of errors. gmake[2]: *** [CMakeFiles/Makefile2:33513: projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/all] Error 2 gmake[2]: Target 'CMakeFiles/check-all.dir/all' not remade because of errors. gmake[1]: *** [CMakeFiles/Makefile2:737: CMakeFiles/check-all.dir/rule] Error 2 gmake[1]: Target 'check-all' not remade because of errors. gmake: *** [Makefile:277: check-all] Error 2 [Release Phase3] check-all failed ``` This is because the `backtrace` function requires `-lexecinfo` on BSD platforms. To fix this, detect the `execinfo` library in `cmake/config-ix.cmake`, and add it to the unit test link flags. Additionally, since the code in `sys::PrintStackTrace` makes use of `itaniumDemangle`, also add `-lLLVMDemangle`. (Note that this is more of a general problem with libLLVMSupport, but I'm looking for a quick fix now so it can be merged to the 8.0 branch.) Reviewers: dberris, hans, mgorny, samsonov Reviewed By: dberris Subscribers: krytarowski, delcypher, erik.pilkington, #sanitizers, emaste, llvm-commits Differential Revision: https://reviews.llvm.org/D57181 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@352234 91177308-0d34-0410-b5e6-96231b3b80d8