summaryrefslogtreecommitdiffstats
path: root/compiler-rt/cmake
Commit message (Collapse)AuthorAgeFilesLines
* [CMake] Fix lld detection after D69685Fangrui Song2019-12-281-1/+1
| | | | | | | | | | | | | | | | | | | D69685 actually broke lld detection for my build (probably due to CMake processing order). Before: ``` build projects/compiler-rt/lib/sanitizer_common/tests/Sanitizer-x86_64-Test-Nolibc: ... bin/clang || ... ``` After: ``` build projects/compiler-rt/lib/sanitizer_common/tests/Sanitizer-x86_64-Test-Nolibc: ... bin/clang bin/lld || ... ``` Differential Revision: https://reviews.llvm.org/D71950
* [CMake] Use correct include path for InstrProfData.inc on DarwinPetr Hosek2019-11-241-1/+4
| | | | | | | | On Darwin, part of the profile runtime is included in the builtin library. f35032e changed the location of InstrProfData.inc but the builtin build for Darwin hasn't been updated to include the new path which causes a breakage when building for Darwin. This change addresses this breakage.
* [cmake] Factor out DEFAULT_SANITIZER_MIN_OSX_VERSIONJulian Lettner2019-11-181-6/+8
|
* Bump sanitizer iOS deployment target to 9.0Julian Lettner2019-11-181-1/+1
| | | | | | | | | | | | | Bump default value for `-miphoneos-version-min=x` to 9.0 (from 8.0). TSan tests that use thread local storage `__thread` (e.g., tls_race.cpp) are failing to link for the iOS simulator (arch=x86_64 and -miphoneos-version-min=8.0) on internal/master (will be submitted to Glacier train): ``` ld: targeted OS version does not support use of thread local variables in _main for architecture x86_64 ``` iOS 9.0 was released 2015.
* Bump sanitizer macOS deployment target to 10.10Julian Lettner2019-11-181-4/+4
| | | | | | | | | | | | Bump default value for `SANITIZER_MIN_OSX_VERSION` to 10.10 (from 10.9). TSan does not work on macOS 10.9 and a nice error message is preferable to an "unreferenced symbol" error when loading the TSan runtime. We could try to only bump the deployment target for TSan, but we would have to invest into adding support for this to our CMake build and it does not seem worth it. macOS 10.10 was released in 2014. rdar://31335781
* [RISCV] Add riscv{32,64} to ALL_CRT_SUPPORTED_ARCH listEdward Jones2019-11-071-1/+1
| | | | | | | This allows crtbegin and crtend to be built, allowing RISC-V to no longer rely on implementations from libgcc. Differential revision: https://reviews.llvm.org/D68393
* [CMake] Prevent adding lld to test dependency (TEST_DEPS) when lld project ↵Kelvin Li2019-11-051-1/+1
| | | | | | | | | | is not built D69405 causes failure if running LIT when the compiler was built without lld. Patch by Anh Tuyen Tran (anhtuyen) Differential Revision: https://reviews.llvm.org/D69685
* [compiler-rt] Use xcrun instead of xcodebuild to find the SDK directoryAlex Richardson2019-10-312-2/+4
| | | | | | | | | | | | | | | | | | Summary: xcodebuild does not work unless XCode is installed whereas xcrun also work when only the Command Line Tools are installed. Unlike the check for the version (D69610), this did not cause an erro for me since the fallback to /usr/include for the OSX sysroot worked. Reviewers: yln, delcypher Reviewed By: yln Subscribers: dberris, mgorny, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69659
* Fix compiler-rt build on macOS without XCodeAlex Richardson2019-10-311-2/+2
| | | | | | | | | | | | | | | | | | Summary: Starting with 8a5bfbe6db2824642bf9a1d27a24c5b6132b244f (D68292) this file unconditionally uses xcodebuild to get the SDK version. On my system this always fails with `xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance` Reviewers: delcypher, yln Reviewed By: delcypher, yln Subscribers: dberris, mgorny, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69610
* [msan] Blacklist __gxx_personality_v0.Evgenii Stepanov2019-10-312-1/+2
| | | | | | | | | | | | | | | | | | | | Summary: Fixes https://bugs.llvm.org/show_bug.cgi?id=31877. Fixes https://github.com/google/sanitizers/issues/1155. Enables exceptions in msan/tsan buid of libcxx, and in msan tests. -fdepfile-entry stuff is a workaround for https://reviews.llvm.org/D69290 (default blacklist missing from -MMD output). Reviewers: pcc, dvyukov Subscribers: mgorny, christof, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69587
* [compiler-rt] cmake: add include(BuiltinTests) to CompilerRTDarwinUtilsPuyan Lotfi2019-10-241-0/+1
| | | | | | | | | In cmake, if TEST_COMPILE_ONLY is set compiler-rt/cmake/Modules/CompilerRTDarwinUtils.cmake invokes try_compile_only() but try_compile_only() is defined in BuiltinTests.cmake and is not included in CompilerRTDarwinUtils.cmake. This patch simply includes it BuiltinTests. Differential Revision: https://reviews.llvm.org/D69410
* Fix lld detection in standalone compiler-rt.Evgenii Stepanov2019-10-241-0/+1
| | | | | | | | | | | | | | | Summary: Right now all hwasan tests on Android are silently disabled because they require "has_lld" and standalone compiler-rt can not (and AFAIK was never able to) set it. Reviewers: pcc Subscribers: dberris, mgorny, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69405
* [Sanitizers] Add support for RISC-V 64-bitSam Elliott2019-10-231-2/+2
| | | | | | | | | | | | | | | | | Summary: This has been tested with gcc trunk on openSUSE Tumbleweed on the HiFive Unleashed. Patch by Andreas Schwab (schwab) Reviewers: luismarques Reviewed By: luismarques Subscribers: mhorne, emaste, luismarques, asb, mgorny, fedor.sergeev, simoncook, kito-cheng, shiva0217, rogfer01, rkruppe, lenary, s.egerton, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D66870
* Revert "Fix lld detection in standalone compiler-rt."Evgenii Stepanov2019-10-221-1/+0
| | | | | | Breaks sanitizer-android buildbot. This reverts commit d56203201f8a1f11abb913c4dfc0bf9c61432d1a.
* Fix lld detection in standalone compiler-rt.Evgeniy Stepanov2019-10-211-0/+1
| | | | | | | | | | | | | | | | | Summary: Right now all hwasan tests on Android are silently disabled because they require "has_lld" and standalone compiler-rt can not (and AFAIK was never able to) set it. Reviewers: pcc, dyung Subscribers: dberris, mgorny, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69196 llvm-svn: 375472
* Revert [Sanitizers] Add support for RISC-V 64-bitSam Elliott2019-10-171-2/+2
| | | | | | This reverts r375132 (git commit 00bbe990c5d4472d5413479a539b3d6edbb3ca7a) llvm-svn: 375136
* [Sanitizers] Add support for RISC-V 64-bitSam Elliott2019-10-171-2/+2
| | | | | | | | | | | | | | | | | | | Summary: This has been tested with gcc trunk on openSUSE Tumbleweed on the HiFive Unleashed. Patch by Andreas Schwab (schwab) Reviewers: luismarques Reviewed By: luismarques Subscribers: mhorne, emaste, luismarques, asb, mgorny, fedor.sergeev, simoncook, kito-cheng, shiva0217, rogfer01, rkruppe, lenary, s.egerton, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D66870 llvm-svn: 375132
* [CMake] Disable building all Darwin libraries (except builtins) for macOS ↵Dan Liew2019-10-161-1/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | i386 when the SDK is >= 10.15. Summary: In the macOS 10.15 SDK the ability to link i386 binaries was removed and in the corresponding OS it is not possible to run macOS i386 binaries. The consequence of these changes meant that targets like `check-asan` would fail because: * Unit tests could not be linked for i386 * Lit tests for i386 would fail due to not being able to execute compiled binaries. The simplest fix to this is to simply disable building for i386 for macOS when using the 10.15 SDK (or newer). This disables building the i386 slice for most compiler-rt libraries and consequently disables the unit and lit tests for macOS i386. Note that because the `DARWIN_osx_ARCHS` CMake variable is a cache variable this patch will have no affect on existing builds unless the existing cache variable is deleted. The simplest way to deal with this is delete existing builds and just do a fresh configure. Note this should not affect the builtins which are managed with the `DARWIN_osx_BUILTIN_ARCHS` CMake cache variable. For those who wish to force using a particular set of architectures when using newer SDKs passing `-DDARWIN_osx_ARCHS=i386;x86_64;x86_64h` to CMake should provide a usable (but completely unsupported) workaround. rdar://problem/55668535 rdar://problem/47939978 Reviewers: kubamracek, yln, azhar, kcc, dvyukov, vitalybuka, cryptoad, eugenis, thakis, phosek Subscribers: mgorny, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D68292 llvm-svn: 374977
* [CMake] Fix the value of `config.target_cflags` for non-macOS Apple ↵Dan Liew2019-10-011-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [NFC] Invoke lipo from CMAKE_LIPO.Puyan Lotfi2019-09-241-1/+3
| | | | | | | This shouldn't change anything, except that a cmake cache file that specifies CMAKE_LIPO can specify an alternate lipo to use. llvm-svn: 372790
* [cmake] Strip quotes in try_compile_onlyHans Wennborg2019-09-191-0/+6
| | | | | | | | | | | | | | | | | After r372209, the compile command can end up including an argument with quotes in it, e.g. -fprofile-instr-use="/foo/bar.profdata" when invoking the compiler with execute_process, the compiler ends up getting that argument with quotes and all, and fails to open the file. This all seems horribly broken, but one way of working around it is to simply strip the quotes from the string here. If they were there to protect a path that's got spaces in it, that wasn't going to work anyway because the string is later split by spaces. llvm-svn: 372312
* Fix bug in `darwin_test_archs()` when the cache variable is set but empty.Dan Liew2019-09-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: If the cache variable named in `${valid_archs}` (e.g. `DARWIN_osx_BUILTIN_ARCHS`) is set in the cache but is empty then the cache check `if(${valid_archs})` will be false so the function will probe the compiler but the `set(...)` command at the end of the function to update the cache variable will be a no-op. This is because `set(...)` will not update an existing cache variable unless the `FORCE` argument is provided. To fix this this patch adds `FORCE` so the cache is always updated. rdar://problem/55323665 Reviewers: vsk, kubamracek Subscribers: mgorny, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D67530 llvm-svn: 371872
* [CMake] Separate the detection Darwin platforms architectures for theDan Liew2019-09-132-31/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | built-ins from the rest of compiler-rt. The detection of supported platform (os) architectures for Darwin relies on the `darwin_test_archs()` CMake function. This is used both for building the builtins (`builtin-config-ix.cmake`) and for the rest of the compiler-rt (`config-ix.cmake`). `darwin_test_archs()` implements a cache, presumably to speed up CMake re-configures. Unfortunately this caching is buggy because it depends on external global state (i.e. the `TEST_COMPILE_ONLY` variable) and this is not taken into account. For `config-ix.cmake` `TEST_COMPILE_ONLY` is not set and for `builtin-config-ix.cmake` `TEST_COMPILE_ONLY` is set to `On`. This makes the `darwin_test_archs()` function racey in the sense that a call from one calling context will poison the cache for the other calling context. This is actually an issue George Karpenkov discovered a while back and had an incomplete patch for (https://reviews.llvm.org/D45337) but this was never merged. To workaround this, this patch switches to using a different set of variables for the platform architecture builtins, i.e. `DARWIN_<OS>_ARCHS` -> `DARWIN_<OS>_BUILTIN_ARCHS`. This avoids the cache poisoning problem because the cached variable names are different. This also has the advantage that the the configured architectures for builtins and the rest of the compiler-rt are now independent and can be set differently if necessary. Note in `darwin_test_archs()` we also now pass `-w` to the compiler because `try_compile_only()` treats compiler warnings as errors. This was extremely fragile because compiler warnings (can easily appear due to a buggy compiler or SDK headers) would cause compiler-rt to think an architecture on Darwin wasn't supported. rdar://problem/48637491 llvm-svn: 371871
* Use host's executable suffix for clang when cross-compiling compiler-rtReid Kleckner2019-09-121-2/+12
| | | | | | | | | | | | | | | | | | | | | When cross-compiling compiler-rt as part of LLVM e. g. for Linux on a Windows host and using the just-built clang as cross-compiler, we set the -DBUILTINS_CMAKE_ARGS="-DCMAKE_SYSTEM_NAME=Linux" flag in top-level cmake invocation, which causes CMAKE_EXECUTABLE_SUFFIX to be an empty string in the nested cmake invocation for building builtins. But the compiler for compiling test cases is meant to be run on host, therefore it may have the '.exe' suffix. Handle this by asking cmake about the host system. Patch by Sergej Jaskiewicz <jaskiewiczs@icloud.com> Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D67401 llvm-svn: 371754
* [cmake] enable x86 libfuzzer on WindowsMatthew G McGovern2019-08-291-0/+2
| | | | | | | | - recent commit https://reviews.llvm.org/D66433 enabled libfuzzer to build on windows, this just enables the option to build as part of the the regular build. llvm-svn: 370390
* [sanitizer] Add lld into dependency of sanitizer_common unittestsVitaly Buka2019-08-271-0/+5
| | | | llvm-svn: 370007
* reland [gtest] Fix printing of StringRef and SmallString in assert messages.Sam McCall2019-08-211-2/+2
| | | | | | | | | Renames GTEST_NO_LLVM_RAW_OSTREAM -> GTEST_NO_LLVM_SUPPORT and guards the new features behind it. This reverts commit a063bcf3ef5a879adbe9639a3c187d876eee0e66. llvm-svn: 369527
* [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 llvm-svn: 368960
* [compiler-rt] Fix running tests on macOS when XCode is not installedAlexander Richardson2019-07-271-6/+13
| | | | | | | | | | | | | | | | | | | | | | | | Summary: If XCode is not installed, `xcodebuild -version -sdk macosx Path` will give xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance In this case the variable OSX_SYSROOT will be empty and OSX_SYSROOT_FLAG is set to "-isysroot" (without a path). This then causes the CompilerRTUnitTestCheckCxx target failed to for me because "${COMPILER_RT_TEST_COMPILER} ${OSX_SYSROOT_FLAG} -E" expanded to "clang -isysroot -E". This results in a warning "sysroot -E does not exist" and the target fails to run because the C++ headers cannot be found. Reviewers: beanz, kubamracek Reviewed By: beanz Subscribers: dberris, mgorny, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D65323 llvm-svn: 367170
* [libFuzzer] Set Android specific ALL_FUZZER_SUPPORTED_ARCHYi Kong2019-07-191-0/+2
| | | | | | Build libFuzzer for all Android supported architectures. llvm-svn: 366525
* Enable compiler-rt on SPARCRainer Orth2019-07-124-5/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 365880
* Add NetBSD LSan supportKamil Rytarowski2019-07-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 365735
* [GWP-ASan] D63736 broke ARMv7/v8 sanitizer bots.Mitch Phillips2019-06-261-1/+1
| | | | | | | | 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. llvm-svn: 364486
* Specify log level for CMake messages (less stderr)Stefan Granitz2019-06-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 363821
* Revert r363633 "[CMake] Fix the value of `config.target_cflags` for ↵Hans Wennborg2019-06-191-26/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [compiler-rt][SystemZ] Work around ASAN failures via -fno-partial-inliningUlrich Weigand2019-06-181-0/+1
| | | | | | | | | | | | | | | | | 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. llvm-svn: 363679
* [CMake] Fix the value of `config.target_cflags` for non-macOS Apple ↵Dan Liew2019-06-171-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [GWP-ASan] Disable GWP-ASan on Android for now.Mitch Phillips2019-06-171-1/+3
| | | | | | | | | | | | | | | | | | | 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 llvm-svn: 363624
* [compiler-rt] Respect CMAKE_NMShoaib Meenai2019-06-151-2/+8
| | | | | | | | | | | 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 llvm-svn: 363483
* Fixed GWP-ASan build breakage. When adding the optional flag parser, there ↵Mitch Phillips2019-06-041-1/+2
| | | | | | was a missing dependency on compiler-rt (and thus SanitizerCommon) for this feature. llvm-svn: 362542
* [builtins] Use libtool for builtins when building for Apple platformPetr Hosek2019-06-041-0/+50
| | | | | | | | | | | | 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 llvm-svn: 362466
* [Driver] Change layout of per-target runtimes to resemble multiarchPetr Hosek2019-05-271-2/+2
| | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 361784
* Use CMAKE_C_COMPILER_ARG1 in compiler invocationPetr Hosek2019-05-191-1/+2
| | | | | | | | | 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 llvm-svn: 361111
* [mips] Always use _LARGEFILE_SOURCE / _FILE_OFFSET_BITS for building MIPS 32-bitSimon Atanasyan2019-05-151-2/+2
| | | | | | | | | | | | | | | | | 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. llvm-svn: 360825
* [GWP-ASan] Initial build files, implementation of PRNG [1].Mitch Phillips2019-05-141-1/+16
| | | | | | | | | | | | | | | | | | 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 llvm-svn: 360710
* [crt] Use -std=c11 for crtbegin.o/crtend.oPetr Hosek2019-05-101-0/+1
| | | | | | | | | The source uses C11 syntax such as comments and some compilers print warnings without specifying this flag. Differential Revision: https://reviews.llvm.org/D61797 llvm-svn: 360459
* [compiler-rt] Create install targets for Darwin librariesShoaib Meenai2019-05-073-44/+66
| | | | | | | | | | | 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 llvm-svn: 360181
* [Lsan] Disabling explicitally FreeBSDDavid Carlier2019-05-031-1/+1
| | | | | | | | | | | | 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 llvm-svn: 359920
* [libFuzzer] Re-enable libFuzzer on i386 Linux and fix testJonathan Metzman2019-05-021-7/+8
| | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 359802
* [compiler-rt] Cleanup the --target and --sysroot handlingPetr Hosek2019-05-011-4/+3
| | | | | | This addresses issue introduced in r359646. llvm-svn: 359650
OpenPOWER on IntegriCloud