maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/compiler-rt/test/fuzzer/CMakeLists.txt

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

120 lines
4.0 KiB
CMake
Raw Normal View History

Move libFuzzer to compiler_rt. Resulting library binaries will be named libclang_rt.fuzzer*, and will be placed in Clang toolchain, allowing redistribution. Differential Revision: https://reviews.llvm.org/D36908 llvm-svn: 311407
2017-08-22 07:25:50 +08:00
set(LIBFUZZER_TEST_DEPS ${SANITIZER_COMMON_LIT_TEST_DEPS})
if (NOT COMPILER_RT_STANDALONE_BUILD)
[cmake][libFuzzer] fixup r337193 to ensure msan/dfsan are not added to test deps for libfuzzer when they're not supported by the platform llvm-svn: 337203
2018-07-17 03:41:49 +08:00
list(APPEND LIBFUZZER_TEST_DEPS fuzzer asan ubsan)
if (COMPILER_RT_HAS_MSAN)
list(APPEND LIBFUZZER_TEST_DEPS msan)
endif()
if (COMPILER_RT_HAS_DFSAN)
list(APPEND LIBFUZZER_TEST_DEPS dfsan)
endif()
Add missing lld checks in sanitizer tests. Do not add an lld dependency when this target does not exist. In this case the system installation of lld is used (or whatever is detected with -fuse-ld=lld by default).
2019-10-29 01:21:01 +08:00
if(NOT APPLE AND COMPILER_RT_HAS_LLD AND TARGET lld)
[libFuzzer] If LLD available, require it to build first. Since we now have a test that requires LLD, make sure it is built before that test runs. llvm-svn: 336932
2018-07-13 02:52:10 +08:00
list(APPEND LIBFUZZER_TEST_DEPS lld)
endif()
Move libFuzzer to compiler_rt. Resulting library binaries will be named libclang_rt.fuzzer*, and will be placed in Clang toolchain, allowing redistribution. Differential Revision: https://reviews.llvm.org/D36908 llvm-svn: 311407
2017-08-22 07:25:50 +08:00
endif()
[CMake] Don't modify `FUZZER_SUPPORTED_ARCH` is place. On a Darwin host we were modifying the `FUZZER_SUPPORTED_ARCH` in place which would strip out non-x86 architectures. This unhelpful if we want to use `FUZZER_SUPPORTED_ARCH` later. To fix this we introduce `FUZZER_TEST_ARCH` which is similar to what we have for for the other sanitizers. For non-Darwin host platforms `FUZZER_TEST_ARCH` is the same as `FUZZER_SUPPORTED_ARCH` but for Darwin host platforms we use `darwin_filter_host_archs(...)` as the previous code did. llvm-svn: 359394
2019-04-28 17:44:53 +08:00
set(FUZZER_TEST_ARCH ${FUZZER_SUPPORTED_ARCH})
[libFuzzer] Filter architectures for testing on Apple platforms. This is done in all other sanitizers, and was missing on libFuzzer. llvm-svn: 335290
2018-06-22 05:19:43 +08:00
if (APPLE)
[CMake] Don't modify `FUZZER_SUPPORTED_ARCH` is place. On a Darwin host we were modifying the `FUZZER_SUPPORTED_ARCH` in place which would strip out non-x86 architectures. This unhelpful if we want to use `FUZZER_SUPPORTED_ARCH` later. To fix this we introduce `FUZZER_TEST_ARCH` which is similar to what we have for for the other sanitizers. For non-Darwin host platforms `FUZZER_TEST_ARCH` is the same as `FUZZER_SUPPORTED_ARCH` but for Darwin host platforms we use `darwin_filter_host_archs(...)` as the previous code did. llvm-svn: 359394
2019-04-28 17:44:53 +08:00
darwin_filter_host_archs(FUZZER_SUPPORTED_ARCH FUZZER_TEST_ARCH)
[libFuzzer] Filter architectures for testing on Apple platforms. This is done in all other sanitizers, and was missing on libFuzzer. llvm-svn: 335290
2018-06-22 05:19:43 +08:00
endif()
Move libFuzzer to compiler_rt. Resulting library binaries will be named libclang_rt.fuzzer*, and will be placed in Clang toolchain, allowing redistribution. Differential Revision: https://reviews.llvm.org/D36908 llvm-svn: 311407
2017-08-22 07:25:50 +08:00
if(COMPILER_RT_INCLUDE_TESTS)
list(APPEND LIBFUZZER_TEST_DEPS FuzzerUnitTests)
Add FuzzedDataProvider helper class / single header library. Summary: This class is useful for writing fuzz target that have multiple inputs. Current CL imports the existing `FuzzedDataProvider` from Chromium without any modifications. Feel free to review it thoroughly, if you're interested, but I'd prefer changing the class in a follow up CL. The CL also introduces an exhaustive test for the library, as the behavior of `FuzzedDataProvider` must not change over time. In follow up CLs I'm planning on changing some implementation details (I can share a doc with some comments to be addressed). After that, we will document how `FuzzedDataProvider` should be used. I have tested this on Linux, Windows and Mac platforms. Reviewers: morehouse, metzman, kcc Reviewed By: morehouse Subscribers: metzman, thakis, rnk, mgorny, ormris, delcypher, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D62733 llvm-svn: 363071
2019-06-11 22:30:18 +08:00
list(APPEND LIBFUZZER_TEST_DEPS FuzzedDataProviderUnitTests)
Move libFuzzer to compiler_rt. Resulting library binaries will be named libclang_rt.fuzzer*, and will be placed in Clang toolchain, allowing redistribution. Differential Revision: https://reviews.llvm.org/D36908 llvm-svn: 311407
2017-08-22 07:25:50 +08:00
endif()
Reland "[libFuzzer] Support using libc++" This is needed in case the users of libFuzzer use libc++ in their code, which the fuzz target (libFuzzer) will be linked against. When libc++ source is available, we build a private version of it and link it against libFuzzer which allows using the same static library against codebases which use both libc++ and libstdc++. Differential Revision: https://reviews.llvm.org/D37631 llvm-svn: 322755
2018-01-18 04:39:14 +08:00
add_custom_target(check-fuzzer)
Move libFuzzer to compiler_rt. Resulting library binaries will be named libclang_rt.fuzzer*, and will be placed in Clang toolchain, allowing redistribution. Differential Revision: https://reviews.llvm.org/D36908 llvm-svn: 311407
2017-08-22 07:25:50 +08:00
if(COMPILER_RT_INCLUDE_TESTS)
# libFuzzer unit tests.
configure_lit_site_cfg(
[compiler-rt] Rename lit.*.cfg.* -> lit.*.cfg.py.* 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
2019-06-28 04:56:04 +08:00
${CMAKE_CURRENT_SOURCE_DIR}/unit/lit.site.cfg.py.in
${CMAKE_CURRENT_BINARY_DIR}/unit/lit.site.cfg.py)
Reland "[libFuzzer] Support using libc++" This is needed in case the users of libFuzzer use libc++ in their code, which the fuzz target (libFuzzer) will be linked against. When libc++ source is available, we build a private version of it and link it against libFuzzer which allows using the same static library against codebases which use both libc++ and libstdc++. Differential Revision: https://reviews.llvm.org/D37631 llvm-svn: 322755
2018-01-18 04:39:14 +08:00
add_lit_testsuite(check-fuzzer-unit "Running Fuzzer unit tests"
${CMAKE_CURRENT_BINARY_DIR}/unit
DEPENDS ${LIBFUZZER_TEST_DEPS})
set_target_properties(check-fuzzer-unit PROPERTIES FOLDER "Compiler-RT Tests")
add_dependencies(check-fuzzer check-fuzzer-unit)
Move libFuzzer to compiler_rt. Resulting library binaries will be named libclang_rt.fuzzer*, and will be placed in Clang toolchain, allowing redistribution. Differential Revision: https://reviews.llvm.org/D36908 llvm-svn: 311407
2017-08-22 07:25:50 +08:00
endif()
Reland "[libFuzzer] Support using libc++" This is needed in case the users of libFuzzer use libc++ in their code, which the fuzz target (libFuzzer) will be linked against. When libc++ source is available, we build a private version of it and link it against libFuzzer which allows using the same static library against codebases which use both libc++ and libstdc++. Differential Revision: https://reviews.llvm.org/D37631 llvm-svn: 322755
2018-01-18 04:39:14 +08:00
macro(test_fuzzer stdlib)
cmake_parse_arguments(TEST "" "" "DEPS" ${ARGN})
string(REPLACE "+" "x" stdlib_name ${stdlib})
string(REPLACE "-" ";" stdlib_list ${stdlib_name})
set(STDLIB_CAPITALIZED "")
foreach(part IN LISTS stdlib_list)
string(SUBSTRING ${part} 0 1 first_letter)
string(TOUPPER ${first_letter} first_letter)
string(REGEX REPLACE "^.(.*)" "${first_letter}\\1" part "${part}")
set(STDLIB_CAPITALIZED "${STDLIB_CAPITALIZED}${part}")
endforeach()
[CMake] Don't modify `FUZZER_SUPPORTED_ARCH` is place. On a Darwin host we were modifying the `FUZZER_SUPPORTED_ARCH` in place which would strip out non-x86 architectures. This unhelpful if we want to use `FUZZER_SUPPORTED_ARCH` later. To fix this we introduce `FUZZER_TEST_ARCH` which is similar to what we have for for the other sanitizers. For non-Darwin host platforms `FUZZER_TEST_ARCH` is the same as `FUZZER_SUPPORTED_ARCH` but for Darwin host platforms we use `darwin_filter_host_archs(...)` as the previous code did. llvm-svn: 359394
2019-04-28 17:44:53 +08:00
foreach(arch ${FUZZER_TEST_ARCH})
Reland "[libFuzzer] Support using libc++" This is needed in case the users of libFuzzer use libc++ in their code, which the fuzz target (libFuzzer) will be linked against. When libc++ source is available, we build a private version of it and link it against libFuzzer which allows using the same static library against codebases which use both libc++ and libstdc++. Differential Revision: https://reviews.llvm.org/D37631 llvm-svn: 322755
2018-01-18 04:39:14 +08:00
set(LIBFUZZER_TEST_COMPILER ${COMPILER_RT_TEST_COMPILER})
get_test_cc_for_arch(${arch} LIBFUZZER_TEST_COMPILER LIBFUZZER_TEST_FLAGS)
Move libFuzzer to compiler_rt. Resulting library binaries will be named libclang_rt.fuzzer*, and will be placed in Clang toolchain, allowing redistribution. Differential Revision: https://reviews.llvm.org/D36908 llvm-svn: 311407
2017-08-22 07:25:50 +08:00
Fix issues with testing for i386 llvm-svn: 359584
2019-05-01 01:58:55 +08:00
set(LIBFUZZER_TEST_TARGET_ARCH ${arch})
[sanitizer] Unify and generalize Apple platforms in CMake and lit test configs 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
2018-06-20 21:33:42 +08:00
set(LIBFUZZER_TEST_APPLE_PLATFORM "osx")
Reland "[libFuzzer] Support using libc++" This is needed in case the users of libFuzzer use libc++ in their code, which the fuzz target (libFuzzer) will be linked against. When libc++ source is available, we build a private version of it and link it against libFuzzer which allows using the same static library against codebases which use both libc++ and libstdc++. Differential Revision: https://reviews.llvm.org/D37631 llvm-svn: 322755
2018-01-18 04:39:14 +08:00
set(LIBFUZZER_TEST_STDLIB ${stdlib})
Move libFuzzer to compiler_rt. Resulting library binaries will be named libclang_rt.fuzzer*, and will be placed in Clang toolchain, allowing redistribution. Differential Revision: https://reviews.llvm.org/D36908 llvm-svn: 311407
2017-08-22 07:25:50 +08:00
Reland "[libFuzzer] Support using libc++" This is needed in case the users of libFuzzer use libc++ in their code, which the fuzz target (libFuzzer) will be linked against. When libc++ source is available, we build a private version of it and link it against libFuzzer which allows using the same static library against codebases which use both libc++ and libstdc++. Differential Revision: https://reviews.llvm.org/D37631 llvm-svn: 322755
2018-01-18 04:39:14 +08:00
string(TOUPPER ${arch} ARCH_UPPER_CASE)
set(CONFIG_NAME ${ARCH_UPPER_CASE}${STDLIB_CAPITALIZED}${OS_NAME}Config)
Remove check-fuzzer from check-all, as tests don't pass on some bots. llvm-svn: 311415
2017-08-22 08:54:57 +08:00
Reland "[libFuzzer] Support using libc++" This is needed in case the users of libFuzzer use libc++ in their code, which the fuzz target (libFuzzer) will be linked against. When libc++ source is available, we build a private version of it and link it against libFuzzer which allows using the same static library against codebases which use both libc++ and libstdc++. Differential Revision: https://reviews.llvm.org/D37631 llvm-svn: 322755
2018-01-18 04:39:14 +08:00
# LIT-based libFuzzer tests.
configure_lit_site_cfg(
[compiler-rt] Rename lit.*.cfg.* -> lit.*.cfg.py.* 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
2019-06-28 04:56:04 +08:00
${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.py.in
${CMAKE_CURRENT_BINARY_DIR}/${CONFIG_NAME}/lit.site.cfg.py
Reland "[libFuzzer] Support using libc++" This is needed in case the users of libFuzzer use libc++ in their code, which the fuzz target (libFuzzer) will be linked against. When libc++ source is available, we build a private version of it and link it against libFuzzer which allows using the same static library against codebases which use both libc++ and libstdc++. Differential Revision: https://reviews.llvm.org/D37631 llvm-svn: 322755
2018-01-18 04:39:14 +08:00
)
[libFuzzer] Support using libc++ This is needed in case the users of libFuzzer use libc++ in their code, which the fuzz target (libFuzzer) will be linked against. When libc++ source is available, we build a private version of it and link it against libFuzzer which allows using the same static library against codebases which use both libc++ and libstdc++. Differential Revision: https://reviews.llvm.org/D37631 llvm-svn: 322604
2018-01-17 08:42:48 +08:00
[libFuzzer] Fix multi-arch build support for fuzzer tests. The bug was not previously exposed as only one architecture is currently supported for libFuzzer. Differential Revision: https://reviews.llvm.org/D47287 llvm-svn: 333242
2018-05-25 07:55:53 +08:00
add_lit_testsuite(check-fuzzer-${stdlib_name}-${arch}
[libFuzzer] Provide more descriptive names for testing targets. llvm-svn: 335289
2018-06-22 05:19:24 +08:00
"Running libFuzzer ${stdlib} tests for arch ${arch}"
[libFuzzer] Fix multi-arch build support for fuzzer tests. The bug was not previously exposed as only one architecture is currently supported for libFuzzer. Differential Revision: https://reviews.llvm.org/D47287 llvm-svn: 333242
2018-05-25 07:55:53 +08:00
${CMAKE_CURRENT_BINARY_DIR}/${CONFIG_NAME}/
Reland "[libFuzzer] Support using libc++" This is needed in case the users of libFuzzer use libc++ in their code, which the fuzz target (libFuzzer) will be linked against. When libc++ source is available, we build a private version of it and link it against libFuzzer which allows using the same static library against codebases which use both libc++ and libstdc++. Differential Revision: https://reviews.llvm.org/D37631 llvm-svn: 322755
2018-01-18 04:39:14 +08:00
DEPENDS ${LIBFUZZER_TEST_DEPS})
if(TEST_DEPS)
[libFuzzer] Fix multi-arch build support for fuzzer tests. The bug was not previously exposed as only one architecture is currently supported for libFuzzer. Differential Revision: https://reviews.llvm.org/D47287 llvm-svn: 333242
2018-05-25 07:55:53 +08:00
add_dependencies(check-fuzzer-${stdlib_name}-${arch} ${TEST_DEPS})
Reland "[libFuzzer] Support using libc++" This is needed in case the users of libFuzzer use libc++ in their code, which the fuzz target (libFuzzer) will be linked against. When libc++ source is available, we build a private version of it and link it against libFuzzer which allows using the same static library against codebases which use both libc++ and libstdc++. Differential Revision: https://reviews.llvm.org/D37631 llvm-svn: 322755
2018-01-18 04:39:14 +08:00
endif()
[libFuzzer] Fix multi-arch build support for fuzzer tests. The bug was not previously exposed as only one architecture is currently supported for libFuzzer. Differential Revision: https://reviews.llvm.org/D47287 llvm-svn: 333242
2018-05-25 07:55:53 +08:00
set_target_properties(check-fuzzer-${stdlib_name}-${arch}
PROPERTIES FOLDER "Compiler-RT Tests")
add_dependencies(check-fuzzer check-fuzzer-${stdlib_name}-${arch})
Reland "[libFuzzer] Support using libc++" This is needed in case the users of libFuzzer use libc++ in their code, which the fuzz target (libFuzzer) will be linked against. When libc++ source is available, we build a private version of it and link it against libFuzzer which allows using the same static library against codebases which use both libc++ and libstdc++. Differential Revision: https://reviews.llvm.org/D37631 llvm-svn: 322755
2018-01-18 04:39:14 +08:00
endforeach()
endmacro()
Revert "[libFuzzer] Support using libc++" This reverts commit r322604: test is failing for standalone compiler-rt. llvm-svn: 322689
2018-01-18 01:24:56 +08:00
Reland "[libFuzzer] Support using libc++" This is needed in case the users of libFuzzer use libc++ in their code, which the fuzz target (libFuzzer) will be linked against. When libc++ source is available, we build a private version of it and link it against libFuzzer which allows using the same static library against codebases which use both libc++ and libstdc++. Differential Revision: https://reviews.llvm.org/D37631 llvm-svn: 322755
2018-01-18 04:39:14 +08:00
test_fuzzer("default")
if("${CMAKE_SYSTEM_NAME}" STREQUAL "Linux")
if(TARGET cxx_shared)
test_fuzzer("libc++" DEPS cxx_shared)
endif()
if(TARGET cxx_static)
test_fuzzer("static-libc++" DEPS cxx_static)
endif()
endif()
[libFuzzer] [NFC] Support multi-arch and multi-OS building and testing Differential Revision: https://reviews.llvm.org/D47296 llvm-svn: 334768
2018-06-15 04:46:07 +08:00
if (APPLE)
[CMake] Fix the value of `config.target_cflags` for non-macOS Apple 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
2019-10-02 07:08:18 +08:00
# FIXME(dliew): This logic should be refactored to the way UBSan Darwin
# testing is done.
[libFuzzer] [NFC] Support multi-arch and multi-OS building and testing Differential Revision: https://reviews.llvm.org/D47296 llvm-svn: 334768
2018-06-15 04:46:07 +08:00
set(EXCLUDE_FROM_ALL ON)
[CMake] Fix the value of `config.target_cflags` for non-macOS Apple 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
2019-10-02 07:08:18 +08:00
list_intersect(FUZZER_TEST_IOS_ARCHS FUZZER_SUPPORTED_ARCH DARWIN_ios_ARCHS)
foreach(arch ${FUZZER_TEST_IOS_ARCHS})
[sanitizer] Unify and generalize Apple platforms in CMake and lit test configs 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
2018-06-20 21:33:42 +08:00
set(LIBFUZZER_TEST_APPLE_PLATFORM "ios")
[libFuzzer] [NFC] Support multi-arch and multi-OS building and testing Differential Revision: https://reviews.llvm.org/D47296 llvm-svn: 334768
2018-06-15 04:46:07 +08:00
set(LIBFUZZER_TEST_TARGET_ARCH ${arch})
[CMake] Fix the value of `config.target_cflags` for non-macOS Apple 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
2019-10-02 07:08:18 +08:00
get_test_cflags_for_apple_platform(
"${LIBFUZZER_TEST_APPLE_PLATFORM}"
"${LIBFUZZER_TEST_TARGET_ARCH}"
LIBFUZZER_TEST_FLAGS
)
[sanitizer] Unify and generalize Apple platforms in CMake and lit test configs 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
2018-06-20 21:33:42 +08:00
set(LIBFUZZER_TEST_CONFIG_SUFFIX "-${arch}-${LIBFUZZER_TEST_APPLE_PLATFORM}")
[libFuzzer] [NFC] Support multi-arch and multi-OS building and testing Differential Revision: https://reviews.llvm.org/D47296 llvm-svn: 334768
2018-06-15 04:46:07 +08:00
string(TOUPPER ${arch} ARCH_UPPER_CASE)
set(CONFIG_NAME "IOS${ARCH_UPPER_CASE}Config")
configure_lit_site_cfg(
[compiler-rt] Rename lit.*.cfg.* -> lit.*.cfg.py.* 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
2019-06-28 04:56:04 +08:00
${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.py.in
${CMAKE_CURRENT_BINARY_DIR}/${CONFIG_NAME}/lit.site.cfg.py
[libFuzzer] [NFC] Support multi-arch and multi-OS building and testing Differential Revision: https://reviews.llvm.org/D47296 llvm-svn: 334768
2018-06-15 04:46:07 +08:00
)
add_lit_testsuite(check-fuzzer-ios-${arch} "libFuzzer iOS ${arch} tests"
${CMAKE_CURRENT_BINARY_DIR}/${CONFIG_NAME}/
DEPENDS ${LIBFUZZER_TEST_DEPS})
endforeach()
set(EXCLUDE_FROM_ALL OFF)
endif()