summaryrefslogtreecommitdiffstats
path: root/compiler-rt/test/tsan/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* [CMake] Fix the value of `config.target_cflags` for non-macOS Apple ↵Dan Liew2019-10-011-29/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | platforms. Attempt #3. 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 third 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. The second attempt (r363633) had to be reverted (r363779) due to a build failure. The failed build was using a modified Apple toolchain where the iOS simulator SDK was missing. This exposed a bug in the existing UBSan test generation code where it was assumed that `COMPILER_RT_ENABLE_IOS` implied that the toolchain supported both iOS and the iOS simulator. This is not true. This has been fixed by using the list `SANITIZER_COMMON_SUPPORTED_OS` for the list of supported Apple platforms for UBSan. For consistency with the other Sanitizers we also now intersect the list of architectures with UBSAN_SUPPORTED_ARCH. rdar://problem/50124489 Differential Revision: https://reviews.llvm.org/D61242 llvm-svn: 373405
* [compiler-rt] Rename lit.*.cfg.* -> lit.*.cfg.py.*Reid Kleckner2019-06-271-8/+8
| | | | | | | | | | | | | These lit configuration files are really Python source code. Using the .py file extension helps editors and tools use the correct language mode. LLVM and Clang already use this convention for lit configuration, this change simply applies it to all of compiler-rt. Reviewers: vitalybuka, dberris Differential Revision: https://reviews.llvm.org/D63658 llvm-svn: 364591
* Revert r363633 "[CMake] Fix the value of `config.target_cflags` for ↵Hans Wennborg2019-06-191-42/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 363779
* [CMake] Fix the value of `config.target_cflags` for non-macOS Apple ↵Dan Liew2019-06-171-28/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 363633
* Revert "[CMake] Fix the value of `config.target_cflags` for non-macOS Apple"Dan Liew2019-04-261-10/+2
| | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 359327
* [CMake] Fix the value of `config.target_cflags` for non-macOS AppleDan Liew2019-04-261-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 359305
* [NFC][TSan][libdispatch] Better CMake variable namesJulian Lettner2019-04-041-2/+2
| | | | llvm-svn: 357664
* [TSan][libdispatch] Enable linking and running of tests on LinuxJulian Lettner2019-03-151-0/+3
| | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 356281
* [compiler-rt] Build custom libcxx with libcxxabiJonas Hahnfeld2019-02-171-0/+1
| | | | | | | | | | | | | | | 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 llvm-svn: 354212
* [sanitizer] Unify and generalize Apple platforms in CMake and lit test configsKuba Mracek2018-06-201-12/+5
| | | | | | | | There's more platforms than just "ios" and "iossim" that we should support, and adding more lit config variables for each platform isn't great. Let's generalize and have a single value that determines what the platform under test is. Differential Revision: https://reviews.llvm.org/D48309 llvm-svn: 335123
* [CMake] Support runtimes and monorepo layouts when looking for libcxxPetr Hosek2017-12-121-1/+1
| | | | | | | | | This also slightly refactors the code that's checking the directory presence which allows eliminating one unnecessary variable. Differential Revision: https://reviews.llvm.org/D40637 llvm-svn: 320446
* Disable TSan tests on Android.Evgeniy Stepanov2017-10-111-1/+1
| | | | | | They never passed. This change excludes them from 'check-all'. llvm-svn: 315512
* Add explicit CMake targets for ASan/TSan iOS Simulator testing and update ↵Kuba Mracek2017-07-121-4/+13
| | | | | | the instructions how to run them. llvm-svn: 307844
* [tsan] Add support for running TSan tests on iOS simulator and devicesKuba Mracek2017-07-101-0/+45
| | | | | | Differential Revision: https://reviews.llvm.org/D35157 llvm-svn: 307537
* [sanitizer] Add macOS minimum deployment target to all compiler invocations ↵Kuba Mracek2016-11-291-9/+1
| | | | | | | | | | in lit tests The Clang driver on macOS decides the deployment target based on various things, like your host OS version, the SDK version and some environment variables, which makes lit tests pass or fail based on your environment. Let's make sure we run all lit tests with `-mmacosx-version-min=${SANITIZER_MIN_OSX_VERSION}` (10.9 unless overriden). Differential Revision: https://reviews.llvm.org/D26929 llvm-svn: 288186
* [compiler-rt] Fix VisualStudio virtual folders layoutEtienne Bergeron2016-07-111-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: This patch is a refactoring of the way cmake 'targets' are grouped. It won't affect non-UI cmake-generators. Clang/LLVM are using a structured way to group targets which ease navigation through Visual Studio UI. The Compiler-RT projects differ from the way Clang/LLVM are grouping targets. This patch doesn't contain behavior changes. Reviewers: kubabrecka, rnk Subscribers: wang0109, llvm-commits, kubabrecka, chrisha Differential Revision: http://reviews.llvm.org/D21952 llvm-svn: 275111
* [tests] Always specify correct config.target_arch when configuring test suite.Alexey Samsonov2016-02-231-0/+1
| | | | llvm-svn: 261601
* [tests] Slightly improve a fix in r260669.Alexey Samsonov2016-02-171-1/+2
| | | | llvm-svn: 261142
* Re-commit r260230 with a fix for clang-cmake-aarch64-42vma.Daniel Sanders2016-02-121-1/+1
| | | | | | | There is now a default name_suffix ('default') which should appease the buildbot and reveal why this builder lacks a suffix. llvm-svn: 260679
* Revert r260669 while the clang-cmake-aarch64-42vma failures is investigated.Daniel Sanders2016-02-121-1/+1
| | | | | | | There's no obvious reason it should fail in this way but it's the only change on the blamelist. I suspect stale lit*.cfg's from previous builds. llvm-svn: 260672
* [msan+tsan] Bring back the tests that disappeared after r260230 and r259512.Daniel Sanders2016-02-121-1/+1
| | | | | | | | | | The lit test-suite containing the unit tests needs to be explicitly specified as an argument to lit.py since it is no longer discovered when the other tests are run (because they are one directory deeper). dfsan, lsan, and sanitizer_common don't show the same problem. llvm-svn: 260669
* [TSan] Use darwin_filter_host_arch to restrict set of test arch on Mac OS.Alexey Samsonov2016-02-021-1/+6
| | | | | | This also reverts r259577 which was a quick-fix to fix buildbots. llvm-svn: 259593
* Re-commit r259512: [tsan] Add a libc++ and lit testsuite for each ↵Daniel Sanders2016-02-021-4/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | ${TSAN_SUPPORTED_ARCH}. Summary: This is a workaround to a problem in the 3.8 release that affects MIPS and possibly other targets where the default is not supported but a sibling is supported. When TSAN_SUPPORTED_ARCH is not empty, cmake currently attempts to build a tsan'd libcxx as well as test tsan for the default target regardless of whether the default target is supported or not. This causes problems on MIPS32 since tsan is supported for MIPS64 but not MIPS32. This patch causes cmake to only build the libcxx and run the lit test-suite for archictures in ${TSAN_SUPPORTED_ARCH} This re-commit fixes an issue where 'check-tsan' continued to look for the tsan'd libc++ in the directory it used to be built in. Reviewers: hans, samsonov Subscribers: tberghammer, llvm-commits, danalbert, srhines, dvyukov Differential Revision: http://reviews.llvm.org/D16685 llvm-svn: 259542
* Revert r259512 - [tsan] Add a libc++ and lit testsuite for each ↵Daniel Sanders2016-02-021-23/+4
| | | | | | | | | ${TSAN_SUPPORTED_ARCH}. check-tsan does not pick up the correct libc++.so. It succeeded on my machine by picking up the libc++.so that was built before making this change. llvm-svn: 259519
* [tsan] Add a libc++ and lit testsuite for each ${TSAN_SUPPORTED_ARCH}.Daniel Sanders2016-02-021-4/+23
| | | | | | | | | | | | | | | | | | | | | | | Summary: This is a workaround to a problem in the 3.8 release that affects MIPS and possibly other targets where the default is not supported but a sibling is supported. When TSAN_SUPPORTED_ARCH is not empty, cmake currently attempts to build a tsan'd libcxx as well as test tsan for the default target regardless of whether the default target is supported or not. This causes problems on MIPS32 since tsan is supported for MIPS64 but not MIPS32. This patch causes cmake to only build the libcxx and run the lit test-suite for archictures in ${TSAN_SUPPORTED_ARCH} Reviewers: hans, samsonov Subscribers: tberghammer, llvm-commits, danalbert, srhines, dvyukov Differential Revision: http://reviews.llvm.org/D16685 llvm-svn: 259512
* [PPC64, TSAN] LLVM basic enablement of thread sanitizer for PPC64 (BE and LE)Bill Schmidt2015-12-081-1/+1
| | | | | | | | | | | | | | | | | | This patch is by Simone Atzeni with portions by Adhemerval Zanella. This contains the LLVM patches to enable the thread sanitizer for PPC64, both big- and little-endian. Two different virtual memory sizes are supported: Old kernels use a 44-bit address space, while newer kernels require a 46-bit address space. There are two companion patches that will be added shortly. There is a Clang patch to actually turn on the use of the thread sanitizer for PPC64. There is also a patch that I wrote to provide interceptor support for setjmp/longjmp on PPC64. Patch discussion at reviews.llvm.org/D12841. llvm-svn: 255057
* [tsan] Enable building and testing TSan Go runtime on OS XKuba Brecka2015-12-041-1/+1
| | | | | | | | The build and test actually work now, so let's just enable them. Differential Revision: http://reviews.llvm.org/D15184 llvm-svn: 254716
* [tsan] Skip building libcxx_tsan on OS XKuba Brecka2015-11-091-1/+2
| | | | | | | | The TSan-instrumented version of libcxx doesn't even build on OS X at this point. Let's skip it from the OS X build for now, since most of TSan functionality doesn't depend on it. This will enable `check-tsan` to be run. Differential Revision: http://reviews.llvm.org/D14486 llvm-svn: 252455
* [tsan] CMake support for TSan on OS XKuba Brecka2015-11-031-1/+1
| | | | | | | | Hi, this patch adds a CMake flag called `COMPILER_RT_ENABLE_TSAN_OSX`, which is off by default. If enabled, the build system will be building the OS X version of the TSan runtime library (called `libclang_rt.tsan_osx_dynamic.dylib`). I'll submit patches that fix OS X build errors shortly. This is part of an effort to port TSan to OS X, and it's one the very first steps. Don't expect TSan on OS X to actually work or pass tests at this point. llvm-svn: 251915
* [CMake] Remove all uses of LLVM_NATIVE_ARCH.Alexey Samsonov2015-09-081-1/+1
| | | | | | | | | | | | | | | | Instead, assume we're going to target triple specified by COMPILER_RT_DEFAULT_TARGET_TRIPLE and build runtimes for this triple (and hope that the host compiler can target them). This will help users that use cross-compiler on their host to build Clang that would work on a different architecture. This will also come in handy if one would want to configure several compiler-rt build trees on the same host, using just-built Clang that can target many architectures. This doesn't change the behavior in the default build configuration. llvm-svn: 247099
* [sanitizer][MIPS] Fix warnings on MIPSDmitry Vyukov2015-04-101-1/+3
| | | | | | | | | | | | Fixed: - stack frame size warning. - msse3 flag unused warning. - GoTsanRuntimeCheck dependency warning reported by cmake. Change by Sagar Thakur Reviewed in http://reviews.llvm.org/D8963 llvm-svn: 234579
* [TSan] Add Go runtime sanity check to CMake build.Alexey Samsonov2015-02-021-0/+1
| | | | llvm-svn: 227852
* [TSan] Fix a bug in libcxx-tsan build conditions spotted by Ryuta SuzukiAlexey Samsonov2014-07-101-1/+1
| | | | llvm-svn: 212749
* [CMake] Don't build libcxx_tsan with compilers other than ClangAlexey Samsonov2014-05-161-1/+2
| | | | llvm-svn: 209003
* [TSan] Build TSan-instrumented version of libcxx and use it in lit tests.Alexey Samsonov2014-05-131-4/+10
| | | | | | | | | | | | | TSan can produce false positives in code that uses C++11 threading, as it doesn't see synchronization inside standard library. See http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-February/035408.html for an example of such case. We may build custom TSan-instrumented version libcxx to fight with that. This change adds build rules for libcxx_tsan and integrates it into testing infrastructure. llvm-svn: 208737
* [CMake] lit tests shouldn't depend on runtimes in standalone buildAlexey Samsonov2014-02-201-3/+4
| | | | llvm-svn: 201771
* [CMake] Introduce COMPILER_RT_INCLUDE_TESTS optionAlexey Samsonov2014-02-191-1/+1
| | | | llvm-svn: 201666
* Move TSan lit-tests under test/tsanAlexey Samsonov2014-02-141-0/+19
llvm-svn: 201414
OpenPOWER on IntegriCloud