summaryrefslogtreecommitdiff
path: root/cmake
Commit message (Collapse)AuthorAgeFilesLines
* [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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@373405 91177308-0d34-0410-b5e6-96231b3b80d8
* [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. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@372790 91177308-0d34-0410-b5e6-96231b3b80d8
* [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. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@372312 91177308-0d34-0410-b5e6-96231b3b80d8
* 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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@371872 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@371871 91177308-0d34-0410-b5e6-96231b3b80d8
* 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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@371754 91177308-0d34-0410-b5e6-96231b3b80d8
* [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. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@370390 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Add lld into dependency of sanitizer_common unittestsVitaly Buka2019-08-271-0/+5
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@370007 91177308-0d34-0410-b5e6-96231b3b80d8
* 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. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@369527 91177308-0d34-0410-b5e6-96231b3b80d8
* [CMake] Check for C++14 instead of C++11Jonas Devlieghere2019-08-151-1/+1
| | | | | | | | | | | | | | | Now that LLVM moved to C++14, `COMPILER_RT_HAS_STD_CXX11_FLAG` should become `COMPILER_RT_HAS_STD_CXX14_FLAG`. I ran into this issue when replacing llvm::make_unique with std::make_unique in an X-ray unit test. We are correctly passing `-std=c++14`, but this got overwritten further down the invocation by the compiler-rt flags. Given that this unit test is using LLVM headers, this is bound to break sooner than later, regardless of my change. Differential revision: https://reviews.llvm.org/D66271 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@368960 91177308-0d34-0410-b5e6-96231b3b80d8
* [compiler-rt] 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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@367170 91177308-0d34-0410-b5e6-96231b3b80d8
* [libFuzzer] Set Android specific ALL_FUZZER_SUPPORTED_ARCHYi Kong2019-07-191-0/+2
| | | | | | Build libFuzzer for all Android supported architectures. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@366525 91177308-0d34-0410-b5e6-96231b3b80d8
* 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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@365880 91177308-0d34-0410-b5e6-96231b3b80d8
* 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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@365735 91177308-0d34-0410-b5e6-96231b3b80d8
* [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. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@364486 91177308-0d34-0410-b5e6-96231b3b80d8
* 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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@363821 91177308-0d34-0410-b5e6-96231b3b80d8
* 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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@363779 91177308-0d34-0410-b5e6-96231b3b80d8
* [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. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@363679 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@363633 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@363624 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@363483 91177308-0d34-0410-b5e6-96231b3b80d8
* 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. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@362542 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@362466 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@361784 91177308-0d34-0410-b5e6-96231b3b80d8
* 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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@361111 91177308-0d34-0410-b5e6-96231b3b80d8
* [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. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@360825 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@360710 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@360459 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@360181 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@359920 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@359802 91177308-0d34-0410-b5e6-96231b3b80d8
* [compiler-rt] Cleanup the --target and --sysroot handlingPetr Hosek2019-05-011-4/+3
| | | | | | This addresses issue introduced in r359646. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@359650 91177308-0d34-0410-b5e6-96231b3b80d8
* [compiler-rt] Pass sysroot and disable pedantic for crtbegin.o/crtend.oPetr Hosek2019-05-012-1/+5
| | | | | | | | 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
* [compiler-rt] Rework the object build supportPetr Hosek2019-05-011-8/+33
| | | | | | | | | | 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
* [libFuzzer] Disable i386 on non-Linux platformsJonathan Metzman2019-05-011-1/+5
| | | | | | | | | | | | | | | | 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
* Reland "[compiler-rt] Simple crtbegin.o and crtend.o implementation"Petr Hosek2019-04-302-17/+43
| | | | | | | | | | | | | | | 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
* Enable x86 buildsJonathan Metzman2019-04-301-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@359583 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[compiler-rt] Simple crtbegin.o and crtend.o implementation"Petr Hosek2019-04-302-43/+17
| | | | | | This reverts commit r359576 since it's failing on Windows bots. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@359579 91177308-0d34-0410-b5e6-96231b3b80d8
* [compiler-rt] Simple crtbegin.o and crtend.o implementationPetr Hosek2019-04-302-17/+43
| | | | | | | | | | | | | | | 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
* Revert "[CMake] Fix the value of `config.target_cflags` for non-macOS Apple"Dan Liew2019-04-261-26/+0
| | | | | | | | | | | | | | | | | | | | | 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
* [CMake] Fix the value of `config.target_cflags` for non-macOS AppleDan Liew2019-04-261-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [compiler-rt] Build custom libc++abi without exceptions.Matt Morehouse2019-04-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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
* [cmake] Change deprecated $<CONFIG> to $<CONFIGURATION>. NFCFangrui Song2019-03-301-1/+1
| | | | | | | 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
* [CMake] Fix broken uses of `try_compile_only()` and improve the function.Dan Liew2019-03-153-4/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [TSan][libdispatch] Enable linking and running of tests on LinuxJulian Lettner2019-03-151-0/+1
| | | | | | | | | | | | | | | | | | | | | 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
* Remove esan.Nico Weber2019-03-111-13/+1
| | | | | | | | | | | 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
* Delete x86_64 ShadowCallStack supportVlad Tsyrklevich2019-03-071-1/+1
| | | | | | | | | | | | | | | | | | | | | 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
* [sanitizer] Build everything whereever possible with -z text.Evgeniy Stepanov2019-03-011-0/+2
| | | | | | | | | | | | Reviewers: pcc, phosek Subscribers: mgorny, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D58755 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@355164 91177308-0d34-0410-b5e6-96231b3b80d8
* [compiler-rt][CMake] Set project for the custom libc++Petr Hosek2019-02-191-0/+1
| | | | | | | | | | | | | 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
* [compiler-rt] Build custom libcxx with libcxxabiJonas Hahnfeld2019-02-172-2/+30
| | | | | | | | | | | | | | | 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
View Lorry Controller Status