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

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

62 lines
1.9 KiB
CMake
Raw Normal View History

Add a test harness Mostly cargo-culted from libcxxabi, since the unwinder was forked from there in the first place. There may still be cruft that's only applicable to libcxxabi, but that can be addressed in-tree. https://reviews.llvm.org/D35038 llvm-svn: 307266
2017-07-06 23:20:12 +08:00
include(AddLLVM) # for add_lit_testsuite
macro(pythonize_bool var)
if (${var})
set(${var} True)
else()
set(${var} False)
endif()
endmacro()
if (NOT DEFINED LIBCXX_ENABLE_SHARED)
set(LIBCXX_ENABLE_SHARED ON)
endif()
pythonize_bool(LIBUNWIND_BUILD_32_BITS)
[libunwind] Support stack unwind in CET environment Control-flow Enforcement Technology (CET), published by Intel, introduces shadow stack feature aiming to ensure a return from a function is directed to where the function was called. In a CET enabled system, each function call will push return address into normal stack and shadow stack, when the function returns, the address stored in shadow stack will be popped and compared with the return address, program will fail if the 2 addresses don't match. In exception handling, the control flow may skip some stack frames and we must adjust shadow stack to avoid violating CET restriction. In order to achieve this, we count the number of stack frames skipped and adjust shadow stack by this number before jumping to landing pad. Reviewed By: hjl.tools, compnerd, MaskRay Differential Revision: https://reviews.llvm.org/D105968 Signed-off-by: gejin <ge.jin@intel.com>
2021-08-26 16:20:38 +08:00
pythonize_bool(LIBUNWIND_ENABLE_CET)
Add a test harness Mostly cargo-culted from libcxxabi, since the unwinder was forked from there in the first place. There may still be cruft that's only applicable to libcxxabi, but that can be addressed in-tree. https://reviews.llvm.org/D35038 llvm-svn: 307266
2017-07-06 23:20:12 +08:00
pythonize_bool(LIBCXX_ENABLE_SHARED)
pythonize_bool(LIBUNWIND_ENABLE_SHARED)
pythonize_bool(LIBUNWIND_ENABLE_THREADS)
Reland "Enable `-funwind-tables` flag when building libunwind" Summary: Relands https://reviews.llvm.org/D70815. The original commit set `CMAKE_TRY_COMPILE_TARGET_TYPE` to `STATIC_LIBRARY` globally in libunwind/CMakeLists.txt, which effectively disabled the linking step in CMake checks. This broke some builds (see 938c70b86c7d2165f8c28d5700e9c1ac1263307e). Here we set CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY only when checking for presence of the `-funwind-tables` flag, and then set it back to the original value so it doesn't affect other checks. Reviewers: mstorsjo, jfb Subscribers: mgorny, christof, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D71117
2019-12-06 22:26:35 +08:00
pythonize_bool(LIBUNWIND_USES_ARM_EHABI)
[CMake] Update lit test configuration There are several changes: - Don't stringify Pythonized bools (that's why we're Pythonizing them) - Support specifying target and sysroot via CMake variables - Use consistent spelling for --target, --sysroot, --gcc-toolchain llvm-svn: 353137
2019-02-05 12:44:03 +08:00
pythonize_bool(LIBUNWIND_USE_COMPILER_RT)
Add a test harness Mostly cargo-culted from libcxxabi, since the unwinder was forked from there in the first place. There may still be cruft that's only applicable to libcxxabi, but that can be addressed in-tree. https://reviews.llvm.org/D35038 llvm-svn: 307266
2017-07-06 23:20:12 +08:00
pythonize_bool(LIBUNWIND_BUILD_EXTERNAL_THREAD_LIBRARY)
set(LIBUNWIND_TARGET_INFO "libcxx.test.target_info.LocalTI" CACHE STRING
"TargetInfo to use when setting up test environment.")
[libc++] Allow specifying arbitrary custom executors with the new format The integration between CMake and executor selection in the new format wasn't very flexible -- only the default executor and SSH executors were supported. This patch makes it possible to specify arbitrary executors with the new format. With the new testing format, a custom executor is just a script that gets called with a command-line to execute, and some arguments like --env, --codesign_identity and --execdir. As such, the default executor is just run.py. Remote execution with the SSH executor can be achived by specifying LIBCXX_EXECUTOR="<path-to-ssh.py> --host <host>". Similarly, arbitrary scripts can be provided.
2020-06-12 03:41:38 +08:00
set(LIBUNWIND_EXECUTOR "${Python3_EXECUTABLE} ${LIBUNWIND_LIBCXX_PATH}/utils/run.py" CACHE STRING
Add a test harness Mostly cargo-culted from libcxxabi, since the unwinder was forked from there in the first place. There may still be cruft that's only applicable to libcxxabi, but that can be addressed in-tree. https://reviews.llvm.org/D35038 llvm-svn: 307266
2017-07-06 23:20:12 +08:00
"Executor to use when running tests.")
set(AUTO_GEN_COMMENT "## Autogenerated by libunwind configuration.\n# Do not edit!")
[libc++] Serialize Lit parameters to make them available to from-scratch configs Before this patch, Lit parameters that were set as a result of CMake options were not made available to from-scratch configs. This patch serializes those parameters into the generated lit config file so that they are available to all configs. Differential Revision: https://reviews.llvm.org/D105047
2021-06-02 05:16:11 +08:00
set(SERIALIZED_LIT_PARAMS "# Lit parameters serialized here for llvm-lit to pick them up\n")
macro(serialize_lit_param param value)
string(APPEND SERIALIZED_LIT_PARAMS "config.${param} = ${value}\n")
endmacro()
serialize_lit_param(enable_experimental False)
if (LLVM_USE_SANITIZER)
serialize_lit_param(use_sanitizer "\"${LLVM_USE_SANITIZER}\"")
endif()
[runtimes] Simplify how we set the target triple Instead of using TARGET_TRIPLE, which is always set to LLVM_DEFAULT_TARGET_TRIPLE, use that variable directly to populate the various XXXX_TARGET_TRIPLE variables in the runtimes. This re-applies 77396bbc98 and 5099e01568, which were reverted in 850b57c5fbe because they broke the build. Differential Revision: https://reviews.llvm.org/D106009
2021-07-15 03:54:13 +08:00
if (LIBUNWIND_TARGET_TRIPLE)
serialize_lit_param(target_triple "\"${LIBUNWIND_TARGET_TRIPLE}\"")
[libc++] Serialize Lit parameters to make them available to from-scratch configs Before this patch, Lit parameters that were set as a result of CMake options were not made available to from-scratch configs. This patch serializes those parameters into the generated lit config file so that they are available to all configs. Differential Revision: https://reviews.llvm.org/D105047
2021-06-02 05:16:11 +08:00
endif()
[runtimes] Move enable_32bit to the DSL This is necessary for from-scratch configurations to support the 32-bit mode of the test suite. Differential Revision: https://reviews.llvm.org/D105435
2021-07-06 00:27:14 +08:00
if (LIBUNWIND_BUILD_32_BITS)
serialize_lit_param(enable_32bit True)
endif()
[runtimes] Serialize all Lit params instead of passing them to add_lit_testsuite add_lit_testsuite() takes Lit parameters passed to it and adds them to the parameters used globally when running all test suites. That means that a target like `check-all`, which ends up calling Lit on the whole monorepo, will see the test parameters for all the individual project's test suites. So, for example, it would see `--param std=c++03` (from libc++abi), and `--param std=c++03` (from libc++), and `--param whatever` (from another project being tested at the same time). While always unclean, that works when the parameters all agree. However, if the parameters share the same name but have different values, only one of those two values will be used and it will be incredibly confusing to understand why one of the test suites is being run with the incorrect parameter value. For that reason, this commit moves away from using add_lit_testsuite()'s PARAM functionality, and serializes the parameter values for the runtimes in the generated config.py file instead, which is local to the specific test suite. Differential Revision: https://reviews.llvm.org/D105991
2021-07-14 23:36:22 +08:00
foreach(param IN LISTS LIBUNWIND_TEST_PARAMS)
string(REGEX REPLACE "(.+)=(.+)" "\\1" name "${param}")
string(REGEX REPLACE "(.+)=(.+)" "\\2" value "${param}")
serialize_lit_param("${name}" "\"${value}\"")
endforeach()
[libunwind] Allow specifying custom Lit config files This is the libunwind counterpart of 0c66af970c80.
2020-06-26 00:02:43 +08:00
configure_lit_site_cfg(
"${LIBUNWIND_TEST_CONFIG}"
Add a test harness Mostly cargo-culted from libcxxabi, since the unwinder was forked from there in the first place. There may still be cruft that's only applicable to libcxxabi, but that can be addressed in-tree. https://reviews.llvm.org/D35038 llvm-svn: 307266
2017-07-06 23:20:12 +08:00
${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
[libunwind] Allow specifying custom Lit config files This is the libunwind counterpart of 0c66af970c80.
2020-06-26 00:02:43 +08:00
MAIN_CONFIG "${CMAKE_CURRENT_SOURCE_DIR}/lit.cfg.py")
Add a test harness Mostly cargo-culted from libcxxabi, since the unwinder was forked from there in the first place. There may still be cruft that's only applicable to libcxxabi, but that can be addressed in-tree. https://reviews.llvm.org/D35038 llvm-svn: 307266
2017-07-06 23:20:12 +08:00
add_lit_testsuite(check-unwind "Running libunwind tests"
${CMAKE_CURRENT_BINARY_DIR}
[runtimes] Serialize all Lit params instead of passing them to add_lit_testsuite add_lit_testsuite() takes Lit parameters passed to it and adds them to the parameters used globally when running all test suites. That means that a target like `check-all`, which ends up calling Lit on the whole monorepo, will see the test parameters for all the individual project's test suites. So, for example, it would see `--param std=c++03` (from libc++abi), and `--param std=c++03` (from libc++), and `--param whatever` (from another project being tested at the same time). While always unclean, that works when the parameters all agree. However, if the parameters share the same name but have different values, only one of those two values will be used and it will be incredibly confusing to understand why one of the test suites is being run with the incorrect parameter value. For that reason, this commit moves away from using add_lit_testsuite()'s PARAM functionality, and serializes the parameter values for the runtimes in the generated config.py file instead, which is local to the specific test suite. Differential Revision: https://reviews.llvm.org/D105991
2021-07-14 23:36:22 +08:00
DEPENDS unwind ${LIBUNWIND_TEST_DEPS})