maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/compiler-rt/cmake/Modules/AddCompilerRT.cmake

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

727 lines
28 KiB
CMake
Raw Normal View History

[CMake] Use ExternalProject to build MSan-ified version of libcxx for unit tests. This change lets MSan rely on libcxx's own build system instead of manually compiling its sources and setting up all the necessary compile flags. It would also simplify compiling libcxx with another sanitizers (in particular, TSan). The tricky part is to make sure libcxx is reconfigured/rebuilt when Clang or MSan runtime library is changed. "clobber" step used in this patch works well for me, but it's possible it would break for other configurations - will watch the buildbots. llvm-svn: 208451
2014-05-10 06:11:03 +08:00
include(ExternalProject)
CMake: create AddCompilerRT module and implement convenience add_compiler_rt_object_library function llvm-svn: 172826
2013-01-19 00:05:21 +08:00
include(CompilerRTUtils)
[compiler-rt] Build with correct ABI (PR38025) Summary: This patch fixes [[ https://bugs.llvm.org/show_bug.cgi?id=38025 | PR38025 ]]: Wrong ABI used when building compiler-rt Differential Revision: https://reviews.llvm.org/D74133
2020-03-28 07:17:52 +08:00
include(HandleCompilerRT)
Significantly change the way we build ASan unittests in CMake build tree. Now just-built Clang is used to: 1) compile instrumented sources (as before); 2) compile non-instrumented sources; 3) compile our own instrumented version of googletest; 4) link it all together using -fsanitize=address flag (instead of trying to copy linker behavior in CMake build rules). This makes ASan unittests pretty much self-consistent and independent of other LLVM libraries. llvm-svn: 170541
2012-12-19 20:33:39 +08:00
[compiler-rt] Fix VisualStudio virtual folders layout Summary: This patch is a refactoring of the way cmake 'targets' are grouped. It won't affect non-UI cmake-generators. Clang/LLVM are using a structured way to group targets which ease navigation through Visual Studio UI. The Compiler-RT projects differ from the way Clang/LLVM are grouping targets. This patch doesn't contain behavior changes. Reviewers: kubabrecka, rnk Subscribers: wang0109, llvm-commits, kubabrecka, chrisha Differential Revision: http://reviews.llvm.org/D21952 llvm-svn: 275111
2016-07-12 05:51:56 +08:00
function(set_target_output_directories target output_dir)
# For RUNTIME_OUTPUT_DIRECTORY variable, Multi-configuration generators
# append a per-configuration subdirectory to the specified directory.
# To avoid the appended folder, the configuration specific variable must be
# set 'RUNTIME_OUTPUT_DIRECTORY_${CONF}':
# RUNTIME_OUTPUT_DIRECTORY_DEBUG, RUNTIME_OUTPUT_DIRECTORY_RELEASE, ...
if(CMAKE_CONFIGURATION_TYPES)
foreach(build_mode ${CMAKE_CONFIGURATION_TYPES})
string(TOUPPER "${build_mode}" CONFIG_SUFFIX)
set_target_properties("${target}" PROPERTIES
"ARCHIVE_OUTPUT_DIRECTORY_${CONFIG_SUFFIX}" ${output_dir}
"LIBRARY_OUTPUT_DIRECTORY_${CONFIG_SUFFIX}" ${output_dir}
"RUNTIME_OUTPUT_DIRECTORY_${CONFIG_SUFFIX}" ${output_dir})
endforeach()
else()
set_target_properties("${target}" PROPERTIES
ARCHIVE_OUTPUT_DIRECTORY ${output_dir}
LIBRARY_OUTPUT_DIRECTORY ${output_dir}
RUNTIME_OUTPUT_DIRECTORY ${output_dir})
endif()
endfunction()
[CMake] Cleanup add_compiler_rt_object_library to be platform-agnostic Summary: This change takes darwin-specific goop that was scattered around CMakeLists files and spread between add_compiler_rt_object_library and add_compiler_rt_darwin_object_library and moves it all under add_compiler_rt_object_library. The goal of this is to try to push platform handling as low in the utility functions as possible. Reviewers: rnk, samsonov Reviewed By: rnk, samsonov Subscribers: rnk, rsmith, llvm-commits Differential Revision: http://reviews.llvm.org/D10250 llvm-svn: 239498
2015-06-11 07:55:07 +08:00
# Tries to add an "object library" target for a given list of OSs and/or
# architectures with name "<name>.<arch>" for non-Darwin platforms if
# architecture can be targeted, and "<name>.<os>" for Darwin platforms.
# add_compiler_rt_object_libraries(<name>
CMake: Stop using LLVM's custom parse_arguments. NFC Summary: Use CMake's cmake_parse_arguments() instead. It's called in a slightly different way, but supports all our use cases. It's in CMake 2.8.8, which is our minimum supported version. CMake 3.0 doc (roughly the same. No direct link to 2.8.8 doc): http://www.cmake.org/cmake/help/v3.0/module/CMakeParseArguments.html?highlight=cmake_parse_arguments Since I was already changing these calls, I changed ARCH and LIB into ARCHS and LIBS to make it more clear that they're lists of arguments. Reviewers: eugenis, samsonov, beanz Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10529 llvm-svn: 240120
2015-06-19 11:39:24 +08:00
# OS <os names>
# ARCHS <architectures>
[CMake] Cleanup add_compiler_rt_object_library to be platform-agnostic Summary: This change takes darwin-specific goop that was scattered around CMakeLists files and spread between add_compiler_rt_object_library and add_compiler_rt_darwin_object_library and moves it all under add_compiler_rt_object_library. The goal of this is to try to push platform handling as low in the utility functions as possible. Reviewers: rnk, samsonov Reviewed By: rnk, samsonov Subscribers: rnk, rsmith, llvm-commits Differential Revision: http://reviews.llvm.org/D10250 llvm-svn: 239498
2015-06-11 07:55:07 +08:00
# SOURCES <source files>
# CFLAGS <compile flags>
[XRay] Set an explicit dependency on libc++ when needed When XRay is being built as part of the just built compiler together with libc++ as part of the runtimes build, we need an explicit dependency from XRay to libc++ to make sure that the library is available by the time we start building XRay. Differential Revision: https://reviews.llvm.org/D48113 llvm-svn: 334575
2018-06-13 15:08:28 +08:00
# DEFS <compile definitions>
[CMake] Add compiler-rt header files to the list of sources for targets when building with an IDE so that header files show up in the UI. This massively improves the development workflow in IDEs. To implement this a new function `compiler_rt_process_sources(...)` has been added that adds header files to the list of sources when the generator is an IDE. For non-IDE generators (e.g. Ninja/Makefile) no changes are made to the list of source files. The function can be passed a list of headers via the `ADDITIONAL_HEADERS` argument. For each runtime library a list of explicit header files has been added and passed via `ADDITIONAL_HEADERS`. For `tsan` and `sanitizer_common` a list of headers was already present but it was stale and has been updated to reflect the current state of the source tree. The original version of this patch used file globbing (`*.{h,inc,def}`) to find the headers but the approach was changed due to this being a CMake anti-pattern (if the list of headers changes CMake won't automatically re-generate if globbing is used). The LLVM repo contains a similar function named `llvm_process_sources()` but we don't use it here for several reasons: * It depends on the `LLVM_ENABLE_OPTION` cache variable which is not set in standalone compiler-rt builds. * We would have to `include(LLVMProcessSources)` which I'd like to avoid because it would include a bunch of stuff we don't need. Differential Revision: https://reviews.llvm.org/D48422 llvm-svn: 336663
2018-07-10 21:00:17 +08:00
# DEPS <dependencies>
# ADDITIONAL_HEADERS <header files>)
[CMake] Cleanup add_compiler_rt_object_library to be platform-agnostic Summary: This change takes darwin-specific goop that was scattered around CMakeLists files and spread between add_compiler_rt_object_library and add_compiler_rt_darwin_object_library and moves it all under add_compiler_rt_object_library. The goal of this is to try to push platform handling as low in the utility functions as possible. Reviewers: rnk, samsonov Reviewed By: rnk, samsonov Subscribers: rnk, rsmith, llvm-commits Differential Revision: http://reviews.llvm.org/D10250 llvm-svn: 239498
2015-06-11 07:55:07 +08:00
function(add_compiler_rt_object_libraries name)
[CMake] Add compiler-rt header files to the list of sources for targets when building with an IDE so that header files show up in the UI. This massively improves the development workflow in IDEs. To implement this a new function `compiler_rt_process_sources(...)` has been added that adds header files to the list of sources when the generator is an IDE. For non-IDE generators (e.g. Ninja/Makefile) no changes are made to the list of source files. The function can be passed a list of headers via the `ADDITIONAL_HEADERS` argument. For each runtime library a list of explicit header files has been added and passed via `ADDITIONAL_HEADERS`. For `tsan` and `sanitizer_common` a list of headers was already present but it was stale and has been updated to reflect the current state of the source tree. The original version of this patch used file globbing (`*.{h,inc,def}`) to find the headers but the approach was changed due to this being a CMake anti-pattern (if the list of headers changes CMake won't automatically re-generate if globbing is used). The LLVM repo contains a similar function named `llvm_process_sources()` but we don't use it here for several reasons: * It depends on the `LLVM_ENABLE_OPTION` cache variable which is not set in standalone compiler-rt builds. * We would have to `include(LLVMProcessSources)` which I'd like to avoid because it would include a bunch of stuff we don't need. Differential Revision: https://reviews.llvm.org/D48422 llvm-svn: 336663
2018-07-10 21:00:17 +08:00
cmake_parse_arguments(LIB "" "" "OS;ARCHS;SOURCES;CFLAGS;DEFS;DEPS;ADDITIONAL_HEADERS"
${ARGN})
[CMake] Cleanup add_compiler_rt_object_library to be platform-agnostic Summary: This change takes darwin-specific goop that was scattered around CMakeLists files and spread between add_compiler_rt_object_library and add_compiler_rt_darwin_object_library and moves it all under add_compiler_rt_object_library. The goal of this is to try to push platform handling as low in the utility functions as possible. Reviewers: rnk, samsonov Reviewed By: rnk, samsonov Subscribers: rnk, rsmith, llvm-commits Differential Revision: http://reviews.llvm.org/D10250 llvm-svn: 239498
2015-06-11 07:55:07 +08:00
set(libnames)
if(APPLE)
foreach(os ${LIB_OS})
set(libname "${name}.${os}")
set(libnames ${libnames} ${libname})
set(extra_cflags_${libname} ${DARWIN_${os}_CFLAGS})
[compiler-rt] list_union() is actually an intersect operation. Rename it. Summary: Given: set(T1 a b c) set(T2 b c d) message("T1=${T1}") message("T2=${T2}") list_union(T3 T1 T2) message("T3=${T3}") cmake emitted: T1=a;b;c T2=b;c;d T3=b;c Reviewers: beanz Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16580 llvm-svn: 258916
2016-01-27 17:28:01 +08:00
list_intersect(LIB_ARCHS_${libname} DARWIN_${os}_ARCHS LIB_ARCHS)
[CMake] Cleanup add_compiler_rt_object_library to be platform-agnostic Summary: This change takes darwin-specific goop that was scattered around CMakeLists files and spread between add_compiler_rt_object_library and add_compiler_rt_darwin_object_library and moves it all under add_compiler_rt_object_library. The goal of this is to try to push platform handling as low in the utility functions as possible. Reviewers: rnk, samsonov Reviewed By: rnk, samsonov Subscribers: rnk, rsmith, llvm-commits Differential Revision: http://reviews.llvm.org/D10250 llvm-svn: 239498
2015-06-11 07:55:07 +08:00
endforeach()
CMake: create AddCompilerRT module and implement convenience add_compiler_rt_object_library function llvm-svn: 172826
2013-01-19 00:05:21 +08:00
else()
CMake: Stop using LLVM's custom parse_arguments. NFC Summary: Use CMake's cmake_parse_arguments() instead. It's called in a slightly different way, but supports all our use cases. It's in CMake 2.8.8, which is our minimum supported version. CMake 3.0 doc (roughly the same. No direct link to 2.8.8 doc): http://www.cmake.org/cmake/help/v3.0/module/CMakeParseArguments.html?highlight=cmake_parse_arguments Since I was already changing these calls, I changed ARCH and LIB into ARCHS and LIBS to make it more clear that they're lists of arguments. Reviewers: eugenis, samsonov, beanz Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10529 llvm-svn: 240120
2015-06-19 11:39:24 +08:00
foreach(arch ${LIB_ARCHS})
[CMake] Cleanup add_compiler_rt_object_library to be platform-agnostic Summary: This change takes darwin-specific goop that was scattered around CMakeLists files and spread between add_compiler_rt_object_library and add_compiler_rt_darwin_object_library and moves it all under add_compiler_rt_object_library. The goal of this is to try to push platform handling as low in the utility functions as possible. Reviewers: rnk, samsonov Reviewed By: rnk, samsonov Subscribers: rnk, rsmith, llvm-commits Differential Revision: http://reviews.llvm.org/D10250 llvm-svn: 239498
2015-06-11 07:55:07 +08:00
set(libname "${name}.${arch}")
set(libnames ${libnames} ${libname})
set(extra_cflags_${libname} ${TARGET_${arch}_CFLAGS})
if(NOT CAN_TARGET_${arch})
Fix typo. llvm-svn: 244475
2015-08-11 02:26:29 +08:00
message(FATAL_ERROR "Architecture ${arch} can't be targeted")
[CMake] Cleanup add_compiler_rt_object_library to be platform-agnostic Summary: This change takes darwin-specific goop that was scattered around CMakeLists files and spread between add_compiler_rt_object_library and add_compiler_rt_darwin_object_library and moves it all under add_compiler_rt_object_library. The goal of this is to try to push platform handling as low in the utility functions as possible. Reviewers: rnk, samsonov Reviewed By: rnk, samsonov Subscribers: rnk, rsmith, llvm-commits Differential Revision: http://reviews.llvm.org/D10250 llvm-svn: 239498
2015-06-11 07:55:07 +08:00
return()
endif()
endforeach()
CMake: create AddCompilerRT module and implement convenience add_compiler_rt_object_library function llvm-svn: 172826
2013-01-19 00:05:21 +08:00
endif()
[compiler-rt] Fix VisualStudio virtual folders layout Summary: This patch is a refactoring of the way cmake 'targets' are grouped. It won't affect non-UI cmake-generators. Clang/LLVM are using a structured way to group targets which ease navigation through Visual Studio UI. The Compiler-RT projects differ from the way Clang/LLVM are grouping targets. This patch doesn't contain behavior changes. Reviewers: kubabrecka, rnk Subscribers: wang0109, llvm-commits, kubabrecka, chrisha Differential Revision: http://reviews.llvm.org/D21952 llvm-svn: 275111
2016-07-12 05:51:56 +08:00
[CMake] Add compiler-rt header files to the list of sources for targets when building with an IDE so that header files show up in the UI. This massively improves the development workflow in IDEs. To implement this a new function `compiler_rt_process_sources(...)` has been added that adds header files to the list of sources when the generator is an IDE. For non-IDE generators (e.g. Ninja/Makefile) no changes are made to the list of source files. The function can be passed a list of headers via the `ADDITIONAL_HEADERS` argument. For each runtime library a list of explicit header files has been added and passed via `ADDITIONAL_HEADERS`. For `tsan` and `sanitizer_common` a list of headers was already present but it was stale and has been updated to reflect the current state of the source tree. The original version of this patch used file globbing (`*.{h,inc,def}`) to find the headers but the approach was changed due to this being a CMake anti-pattern (if the list of headers changes CMake won't automatically re-generate if globbing is used). The LLVM repo contains a similar function named `llvm_process_sources()` but we don't use it here for several reasons: * It depends on the `LLVM_ENABLE_OPTION` cache variable which is not set in standalone compiler-rt builds. * We would have to `include(LLVMProcessSources)` which I'd like to avoid because it would include a bunch of stuff we don't need. Differential Revision: https://reviews.llvm.org/D48422 llvm-svn: 336663
2018-07-10 21:00:17 +08:00
# Add headers to LIB_SOURCES for IDEs
compiler_rt_process_sources(LIB_SOURCES
${LIB_SOURCES}
ADDITIONAL_HEADERS
${LIB_ADDITIONAL_HEADERS}
)
[CMake] Cleanup add_compiler_rt_object_library to be platform-agnostic Summary: This change takes darwin-specific goop that was scattered around CMakeLists files and spread between add_compiler_rt_object_library and add_compiler_rt_darwin_object_library and moves it all under add_compiler_rt_object_library. The goal of this is to try to push platform handling as low in the utility functions as possible. Reviewers: rnk, samsonov Reviewed By: rnk, samsonov Subscribers: rnk, rsmith, llvm-commits Differential Revision: http://reviews.llvm.org/D10250 llvm-svn: 239498
2015-06-11 07:55:07 +08:00
foreach(libname ${libnames})
add_library(${libname} OBJECT ${LIB_SOURCES})
[XRay] Set an explicit dependency on libc++ when needed When XRay is being built as part of the just built compiler together with libc++ as part of the runtimes build, we need an explicit dependency from XRay to libc++ to make sure that the library is available by the time we start building XRay. Differential Revision: https://reviews.llvm.org/D48113 llvm-svn: 334575
2018-06-13 15:08:28 +08:00
if(LIB_DEPS)
add_dependencies(${libname} ${LIB_DEPS})
endif()
[cmake] Work around more -Wunused-driver-argument warnings add_compiler_rt_object_libraries should strip out the -msse3 option on non-macOS Apple platforms. llvm-svn: 312688
2017-09-07 09:36:47 +08:00
# Strip out -msse3 if this isn't macOS.
set(target_flags ${LIB_CFLAGS})
if(APPLE AND NOT "${libname}" MATCHES ".*\.osx.*")
list(REMOVE_ITEM target_flags "-msse3")
endif()
Revert "[cmake] Remove duplicate command line options from build" The Android sanitizer buildbot is failing with this change and it looks like an additional change to cmake is necessary to fix the build. Reverting this change for now. llvm-svn: 329828
2018-04-12 01:31:18 +08:00
set_target_compile_flags(${libname}
[compiler-rt] Don't explicitly set CMAKE_CXX_FLAGS. Summary: C++ flags should not be used for not-C++ files as it may trigger -Werror=unused-command-line-argument. CMake will use CMAKE_C_FLAGS, CMAKE_CXX_FLAGS, and CMAKE_ASM_FLAGS as appropriate implicitly, so this does not need to be explicitly handled here. This change depends on https://reviews.llvm.org/D53301, since one of the builders depended on this behavior because it was not configuring CMAKE_ASM_FLAGS. Reviewers: eugenis, vitalybuka Reviewed By: eugenis, vitalybuka Subscribers: dberris, mgorny, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D53335 llvm-svn: 344751
2018-10-19 02:04:28 +08:00
${extra_cflags_${libname}} ${target_flags})
[CMake] Cleanup add_compiler_rt_object_library to be platform-agnostic Summary: This change takes darwin-specific goop that was scattered around CMakeLists files and spread between add_compiler_rt_object_library and add_compiler_rt_darwin_object_library and moves it all under add_compiler_rt_object_library. The goal of this is to try to push platform handling as low in the utility functions as possible. Reviewers: rnk, samsonov Reviewed By: rnk, samsonov Subscribers: rnk, rsmith, llvm-commits Differential Revision: http://reviews.llvm.org/D10250 llvm-svn: 239498
2015-06-11 07:55:07 +08:00
set_property(TARGET ${libname} APPEND PROPERTY
COMPILE_DEFINITIONS ${LIB_DEFS})
[compiler-rt] Fix VisualStudio virtual folders layout Summary: This patch is a refactoring of the way cmake 'targets' are grouped. It won't affect non-UI cmake-generators. Clang/LLVM are using a structured way to group targets which ease navigation through Visual Studio UI. The Compiler-RT projects differ from the way Clang/LLVM are grouping targets. This patch doesn't contain behavior changes. Reviewers: kubabrecka, rnk Subscribers: wang0109, llvm-commits, kubabrecka, chrisha Differential Revision: http://reviews.llvm.org/D21952 llvm-svn: 275111
2016-07-12 05:51:56 +08:00
set_target_properties(${libname} PROPERTIES FOLDER "Compiler-RT Libraries")
[CMake] Cleanup add_compiler_rt_object_library to be platform-agnostic Summary: This change takes darwin-specific goop that was scattered around CMakeLists files and spread between add_compiler_rt_object_library and add_compiler_rt_darwin_object_library and moves it all under add_compiler_rt_object_library. The goal of this is to try to push platform handling as low in the utility functions as possible. Reviewers: rnk, samsonov Reviewed By: rnk, samsonov Subscribers: rnk, rsmith, llvm-commits Differential Revision: http://reviews.llvm.org/D10250 llvm-svn: 239498
2015-06-11 07:55:07 +08:00
if(APPLE)
[CMake] Add experimental support for building compiler-rt for iOS Summary: This is a reunification of three separate reviews D11073, D11082, D11083. Having them separate was not constructive even though the patches were smaller because it led to fragmented conversations, and this is really all about one change. This patch incorporates feedback from samsonov, and refactors the hacky darwin code out of the root CMakeLists.txt and int config-ix.cmake. Reviewers: zaks.anna, bogner, kubabrecka, chandlerc, samsonov Subscribers: jevinskie, filcab, llvm-commits Differential Revision: http://reviews.llvm.org/D11820 llvm-svn: 244948
2015-08-14 04:38:16 +08:00
set_target_properties(${libname} PROPERTIES
OSX_ARCHITECTURES "${LIB_ARCHS_${libname}}")
[CMake] Cleanup add_compiler_rt_object_library to be platform-agnostic Summary: This change takes darwin-specific goop that was scattered around CMakeLists files and spread between add_compiler_rt_object_library and add_compiler_rt_darwin_object_library and moves it all under add_compiler_rt_object_library. The goal of this is to try to push platform handling as low in the utility functions as possible. Reviewers: rnk, samsonov Reviewed By: rnk, samsonov Subscribers: rnk, rsmith, llvm-commits Differential Revision: http://reviews.llvm.org/D10250 llvm-svn: 239498
2015-06-11 07:55:07 +08:00
endif()
endforeach()
endfunction()
CMake: Add add_compiler_rt_osx_object_library to create universal libraries on Mac llvm-svn: 172979
2013-01-20 22:36:12 +08:00
[CMake] Add OBJECT_LIBS option to add_compiler_rt_runtime, and refactored asan call site to use it. Summary: This is one more step to allow us to eliminate platform-specific code from the library CMakeLists files. Subsequent patches will refactor all call sites to use this and other new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12339 llvm-svn: 246047
2015-08-27 02:33:51 +08:00
# Takes a list of object library targets, and a suffix and appends the proper
# TARGET_OBJECTS string to the output variable.
# format_object_libs(<output> <suffix> ...)
macro(format_object_libs output suffix)
foreach(lib ${ARGN})
list(APPEND ${output} $<TARGET_OBJECTS:${lib}.${suffix}>)
endforeach()
endmacro()
[CMake] Connect Compiler-RT targets to LLVM Runtimes directory This patch builds on LLVM r279776. In this patch I've done some cleanup and abstracted three common steps runtime components have in their CMakeLists files, and added a fourth. The three steps I abstract are: (1) Add a top-level target (i.e asan, msan, ...) (2) Set the target properties for sorting files in IDE generators (3) Make the compiler-rt target depend on the top-level target The new step is to check if a command named "runtime_register_component" is defined, and to call it with the component name. The runtime_register_component command is defined in llvm/runtimes/CMakeLists.txt, and presently just adds the component to a list of sub-components, which later gets used to generate target mappings. With this patch a new workflow for runtimes builds is supported. The new workflow when building runtimes from the LLVM runtimes directory is: > cmake [...] > ninja runtimes-configure > ninja asan The "runtimes-configure" target builds all the dependencies for configuring the runtimes projects, and runs CMake on the runtimes projects. Running the runtimes CMake generates a list of targets to bind into the top-level CMake so subsequent build invocations will have access to some of Compiler-RT's targets through the top-level build. Note: This patch does exclude some top-level targets from compiler-rt libraries because they either don't install files (sanitizer_common), or don't have a cooresponding `check` target (stats). llvm-svn: 279863
2016-08-27 04:52:22 +08:00
function(add_compiler_rt_component name)
add_custom_target(${name})
set_target_properties(${name} PROPERTIES FOLDER "Compiler-RT Misc")
if(COMMAND runtime_register_component)
runtime_register_component(${name})
endif()
add_dependencies(compiler-rt ${name})
endfunction()
[sanitizer] Refactor how assembly files are handled This renames ASM_TSAN_SYMBOL and ASM_TSAN_SYMBOL_INTERCEPTOR to just ASM_SYMBOL and ASM_SYMBOL_INTERCEPTOR, because they can be useful in more places than just TSan. Also introduce a CMake function to add ASM sources to a target. Differential Revision: https://reviews.llvm.org/D40143 llvm-svn: 319339
2017-11-30 03:27:25 +08:00
function(add_asm_sources output)
set(${output} ${ARGN} PARENT_SCOPE)
[CMake][compiler-rt][libunwind] Compile assembly files as ASM not C, unify workarounds It isn't very wise to pass an assembly file to the compiler and tell it to compile as a C file and hope that the compiler recognizes it as assembly instead. Simply don't mark the file as C and CMake will recognize the rest. This was attempted earlier in https://reviews.llvm.org/D85706, but reverted due to architecture issues on Apple. Subsequent digging revealed a similar change was done earlier for libunwind in https://reviews.llvm.org/rGb780df052dd2b246a760d00e00f7de9ebdab9d09. Afterwards workarounds were added for MinGW and Apple: * https://reviews.llvm.org/rGb780df052dd2b246a760d00e00f7de9ebdab9d09 * https://reviews.llvm.org/rGd4ded05ba851304b26a437896bc3962ef56f62cb The workarounds in libunwind and compiler-rt are unified and comments added pointing to each other. The workaround is updated to only be used for MinGW for CMake versions before 3.17, which fixed the issue (https://gitlab.kitware.com/cmake/cmake/-/merge_requests/4287). Additionally fixed Clang not being passed as the assembly compiler for compiler-rt runtime build. Example error: [525/634] Building C object lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o FAILED: lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o /opt/tooling/drive/host/bin/clang --target=aarch64-linux-gnu -I/opt/tooling/drive/llvm/compiler-rt/lib/tsan/.. -isystem /opt/tooling/drive/toolchain/opt/drive/toolchain/include -x c -Wall -Wno-unused-parameter -fno-lto -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -O3 -gline-tables-only -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -Wno-non-virtual-dtor -fPIE -fno-rtti -Wframe-larger-than=530 -Wglobal-constructors --sysroot=. -MD -MT lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o -MF lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o.d -o lib/tsan/CMakeFiles/clang_rt.tsan-aarch64.dir/rtl/tsan_rtl_aarch64.S.o -c /opt/tooling/drive/llvm/compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S /opt/tooling/drive/llvm/compiler-rt/lib/tsan/rtl/tsan_rtl_aarch64.S:29:1: error: expected identifier or '(' .section .text ^ 1 error generated. Differential Revision: https://reviews.llvm.org/D86308
2020-08-21 01:17:47 +08:00
# CMake doesn't pass the correct architecture for Apple prior to CMake 3.19. https://gitlab.kitware.com/cmake/cmake/-/issues/20771
# MinGW didn't work correctly with assembly prior to CMake 3.17. https://gitlab.kitware.com/cmake/cmake/-/merge_requests/4287 and https://reviews.llvm.org/rGb780df052dd2b246a760d00e00f7de9ebdab9d09
# Workaround these two issues by compiling as C.
# Same workaround used in libunwind. Also update there if changed here.
if((APPLE AND CMAKE_VERSION VERSION_LESS 3.19) OR (MINGW AND CMAKE_VERSION VERSION_LESS 3.17))
Revert "[compiler-rt] Compile assembly files as ASM not C" This reverts commit d58fd4e52197d55bf42ca446c8b0ed31b5c2ec1f. This broke compiler-rt compilation on macOS: codesign --sign - /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/lib/clang/12.0.99/lib/darwin/libclang_rt.tsan_ios_dynamic.dylib ld: warning: ignoring file projects/compiler-rt/lib/tsan/CMakeFiles/clang_rt.tsan_ios_dynamic.dir/rtl/tsan_rtl_amd64.S.o, building for iOS-arm64 but attempting to link with file built for iOS Simulator-x86_64 ld: warning: ignoring file projects/compiler-rt/lib/tsan/CMakeFiles/clang_rt.tsan_ios_dynamic.dir/rtl/tsan_rtl_aarch64.S.o, building for iOS-arm64 but attempting to link with file built for iOS Simulator-x86_64 Undefined symbols for architecture arm64: "_wrap__setjmp", referenced from: substitution__setjmp in tsan_interceptors_posix.cpp.o "_wrap_setjmp", referenced from: substitution_setjmp in tsan_interceptors_posix.cpp.o "_wrap_sigsetjmp", referenced from: substitution_sigsetjmp in tsan_interceptors_posix.cpp.o ld: symbol(s) not found for architecture arm64
2020-08-20 21:23:50 +08:00
set_source_files_properties(${ARGN} PROPERTIES LANGUAGE C)
endif()
[sanitizer] Refactor how assembly files are handled This renames ASM_TSAN_SYMBOL and ASM_TSAN_SYMBOL_INTERCEPTOR to just ASM_SYMBOL and ASM_SYMBOL_INTERCEPTOR, because they can be useful in more places than just TSan. Also introduce a CMake function to add ASM sources to a target. Differential Revision: https://reviews.llvm.org/D40143 llvm-svn: 319339
2017-11-30 03:27:25 +08:00
endfunction()
Restore clang_rt library name on i686-android. Summary: Recent changes canonicalized clang_rt library names to refer to "i386" on all x86 targets. Android historically uses i686. This change adds a special case to keep i686 in all clang_rt libraries when targeting Android. Reviewers: hans, mgorny, beanz Subscribers: srhines, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D37278 llvm-svn: 312048
2017-08-30 06:12:31 +08:00
macro(set_output_name output name arch)
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
if(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR)
set(${output} ${name})
Restore clang_rt library name on i686-android. Summary: Recent changes canonicalized clang_rt library names to refer to "i386" on all x86 targets. Android historically uses i686. This change adds a special case to keep i686 in all clang_rt libraries when targeting Android. Reviewers: hans, mgorny, beanz Subscribers: srhines, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D37278 llvm-svn: 312048
2017-08-30 06:12:31 +08:00
else()
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
if(ANDROID AND ${arch} STREQUAL "i386")
set(${output} "${name}-i686${COMPILER_RT_OS_SUFFIX}")
else()
set(${output} "${name}-${arch}${COMPILER_RT_OS_SUFFIX}")
endif()
Restore clang_rt library name on i686-android. Summary: Recent changes canonicalized clang_rt library names to refer to "i386" on all x86 targets. Android historically uses i686. This change adds a special case to keep i686 in all clang_rt libraries when targeting Android. Reviewers: hans, mgorny, beanz Subscribers: srhines, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D37278 llvm-svn: 312048
2017-08-30 06:12:31 +08:00
endif()
endmacro()
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
# Adds static or shared runtime for a list of architectures and operating
# systems and puts it in the proper directory in the build and install trees.
# add_compiler_rt_runtime(<name>
Reland "[compiler-rt] Simple crtbegin.o and crtend.o implementation" 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 llvm-svn: 359591
2019-05-01 02:13:22 +08:00
# {OBJECT|STATIC|SHARED}
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
# ARCHS <architectures>
# OS <os list>
[CMake] Rename add_compiler_rt_static_runtime to add_compiler_rt_runtime. Soon there will be an option to build compiler-rt parts as shared libraries on Linux. Extracted from http://llvm-reviews.chandlerc.com/D3042 by Yuri Gribov. llvm-svn: 205183
2014-03-31 21:45:36 +08:00
# SOURCES <source files>
# CFLAGS <compile flags>
Make cmake link flag naming consistent Summary: The build system was inconsistent in its naming conventions for link flags. This patch changes all uses of LINKFLAGS to LINK_FLAGS, for consistency with cmake's LINK_FLAGS property. This patch should make it easier to search the source code for uses of link flags, as well as providing the benefit of improved style and consistency. Reviewers: compnerd, beanz Subscribers: kubabrecka, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D28506 llvm-svn: 291539
2017-01-10 12:33:04 +08:00
# LINK_FLAGS <linker flags>
[sanitizer] Android build cleanup. * Detect Android toolchain target arch and set correct runtime library name. * Merged a lot of Android and non-Android code paths. * Android is only supported in standalone build of compiler-rt now. * Linking lsan-common in ASan-Android (makes lsan annotations work). * Relying on -fsanitize=address linker flag when building tests (again, unification with non-Android path). * Runtime library moved from lib/asan to lib/linux. llvm-svn: 218605
2014-09-29 21:18:55 +08:00
# DEFS <compile definitions>
[CMake] Track TSan's dependency on C++ headers TSan relies on C++ headers, so when libc++ is being built as part of the runtimes build, include an explicit dependency on cxx-headers which is the same approach that's already used for other sanitizers. Differential Revision: https://reviews.llvm.org/D88912
2020-10-07 02:32:57 +08:00
# DEPS <dependencies>
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
# LINK_LIBS <linked libraries> (only for shared library)
[CMake] Add OBJECT_LIBS option to add_compiler_rt_runtime, and refactored asan call site to use it. Summary: This is one more step to allow us to eliminate platform-specific code from the library CMakeLists files. Subsequent patches will refactor all call sites to use this and other new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12339 llvm-svn: 246047
2015-08-27 02:33:51 +08:00
# OBJECT_LIBS <object libraries to use as sources>
[CMake] Add compiler-rt header files to the list of sources for targets when building with an IDE so that header files show up in the UI. This massively improves the development workflow in IDEs. To implement this a new function `compiler_rt_process_sources(...)` has been added that adds header files to the list of sources when the generator is an IDE. For non-IDE generators (e.g. Ninja/Makefile) no changes are made to the list of source files. The function can be passed a list of headers via the `ADDITIONAL_HEADERS` argument. For each runtime library a list of explicit header files has been added and passed via `ADDITIONAL_HEADERS`. For `tsan` and `sanitizer_common` a list of headers was already present but it was stale and has been updated to reflect the current state of the source tree. The original version of this patch used file globbing (`*.{h,inc,def}`) to find the headers but the approach was changed due to this being a CMake anti-pattern (if the list of headers changes CMake won't automatically re-generate if globbing is used). The LLVM repo contains a similar function named `llvm_process_sources()` but we don't use it here for several reasons: * It depends on the `LLVM_ENABLE_OPTION` cache variable which is not set in standalone compiler-rt builds. * We would have to `include(LLVMProcessSources)` which I'd like to avoid because it would include a bunch of stuff we don't need. Differential Revision: https://reviews.llvm.org/D48422 llvm-svn: 336663
2018-07-10 21:00:17 +08:00
# PARENT_TARGET <convenience parent target>
# ADDITIONAL_HEADERS <header files>)
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
function(add_compiler_rt_runtime name type)
Reland "[compiler-rt] Simple crtbegin.o and crtend.o implementation" 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 llvm-svn: 359591
2019-05-01 02:13:22 +08:00
if(NOT type MATCHES "^(OBJECT|STATIC|SHARED)$")
message(FATAL_ERROR "type argument must be OBJECT, STATIC or SHARED")
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
return()
endif()
cmake_parse_arguments(LIB
""
"PARENT_TARGET"
[CMake] Track TSan's dependency on C++ headers TSan relies on C++ headers, so when libc++ is being built as part of the runtimes build, include an explicit dependency on cxx-headers which is the same approach that's already used for other sanitizers. Differential Revision: https://reviews.llvm.org/D88912
2020-10-07 02:32:57 +08:00
"OS;ARCHS;SOURCES;CFLAGS;LINK_FLAGS;DEFS;DEPS;LINK_LIBS;OBJECT_LIBS;ADDITIONAL_HEADERS"
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
${ARGN})
set(libnames)
[compiler-rt] build compiler-rt runtimes without LTO Summary: Currently, we build the compiler-rt runtimes with link-time optimization if LTO is configured for the LLVM project. This will break external programs that don't invoke the linker in such a way that it supports LLVM's LTO. To avoid this, this change causes the compiler-rt runtimes to be compiled with -fno-lto. This also makes the check-profile tests work on systems when doing a lld LTO build on a system where the system linker does not support LLVM LTO. Reviewers: rnk, davidxl Reviewed By: davidxl Subscribers: dberris, mgorny, llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D31218 llvm-svn: 298525
2017-03-23 01:25:49 +08:00
# Until we support this some other way, build compiler-rt runtime without LTO
# to allow non-LTO projects to link with it.
if(COMPILER_RT_HAS_FNO_LTO_FLAG)
set(NO_LTO_FLAGS "-fno-lto")
else()
set(NO_LTO_FLAGS "")
endif()
[cmake] Work around -Wunused-driver-argument warnings Fix the Darwin logic so that -msse3 is only used on macOS, and -fomit-frame-pointer is not used on armv7/armv7k/armv7s. llvm-svn: 312390
2017-09-02 07:23:59 +08:00
[cmake] By default do not build compiler-rt with PGO Patch by Zhizhou Yang! In his own words: """ Currently compiler-rt doesn't officially support either PGO instrumentation or use PGO profdata to build it. PGO related flags are passed into compiler-rt since rL372209, and causing bugs: 45022, crbug:1018840 This patch adds several checks in compiler-rt to disable PGO related flags and provides a flag to turn on PGO for compiler-rt if needed. """ Differential Revision: https://reviews.llvm.org/D75499
2020-03-10 06:25:41 +08:00
# By default do not instrument or use profdata for compiler-rt.
set(NO_PGO_FLAGS "")
if(NOT COMPILER_RT_ENABLE_PGO)
if(LLVM_PROFDATA_FILE AND COMPILER_RT_HAS_FNO_PROFILE_INSTR_USE_FLAG)
list(APPEND NO_PGO_FLAGS "-fno-profile-instr-use")
endif()
if(LLVM_BUILD_INSTRUMENTED MATCHES IR AND COMPILER_RT_HAS_FNO_PROFILE_GENERATE_FLAG)
list(APPEND NO_PGO_FLAGS "-fno-profile-generate")
elseif(LLVM_BUILD_INSTRUMENTED AND COMPILER_RT_HAS_FNO_PROFILE_INSTR_GENERATE_FLAG)
list(APPEND NO_PGO_FLAGS "-fno-profile-instr-generate")
endif()
endif()
[CMake] Add compiler-rt header files to the list of sources for targets when building with an IDE so that header files show up in the UI. This massively improves the development workflow in IDEs. To implement this a new function `compiler_rt_process_sources(...)` has been added that adds header files to the list of sources when the generator is an IDE. For non-IDE generators (e.g. Ninja/Makefile) no changes are made to the list of source files. The function can be passed a list of headers via the `ADDITIONAL_HEADERS` argument. For each runtime library a list of explicit header files has been added and passed via `ADDITIONAL_HEADERS`. For `tsan` and `sanitizer_common` a list of headers was already present but it was stale and has been updated to reflect the current state of the source tree. The original version of this patch used file globbing (`*.{h,inc,def}`) to find the headers but the approach was changed due to this being a CMake anti-pattern (if the list of headers changes CMake won't automatically re-generate if globbing is used). The LLVM repo contains a similar function named `llvm_process_sources()` but we don't use it here for several reasons: * It depends on the `LLVM_ENABLE_OPTION` cache variable which is not set in standalone compiler-rt builds. * We would have to `include(LLVMProcessSources)` which I'd like to avoid because it would include a bunch of stuff we don't need. Differential Revision: https://reviews.llvm.org/D48422 llvm-svn: 336663
2018-07-10 21:00:17 +08:00
list(LENGTH LIB_SOURCES LIB_SOURCES_LENGTH)
if (${LIB_SOURCES_LENGTH} GREATER 0)
# Add headers to LIB_SOURCES for IDEs. It doesn't make sense to
# do this for a runtime library that only consists of OBJECT
# libraries, so only add the headers when source files are present.
compiler_rt_process_sources(LIB_SOURCES
${LIB_SOURCES}
ADDITIONAL_HEADERS
${LIB_ADDITIONAL_HEADERS}
)
endif()
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
if(APPLE)
foreach(os ${LIB_OS})
[cmake] Work around -Wunused-driver-argument warnings Fix the Darwin logic so that -msse3 is only used on macOS, and -fomit-frame-pointer is not used on armv7/armv7k/armv7s. llvm-svn: 312390
2017-09-02 07:23:59 +08:00
# Strip out -msse3 if this isn't macOS.
list(LENGTH LIB_CFLAGS HAS_EXTRA_CFLAGS)
if(HAS_EXTRA_CFLAGS AND NOT "${os}" MATCHES "^(osx)$")
list(REMOVE_ITEM LIB_CFLAGS "-msse3")
endif()
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
if(type STREQUAL "STATIC")
set(libname "${name}_${os}")
else()
set(libname "${name}_${os}_dynamic")
Make cmake link flag naming consistent Summary: The build system was inconsistent in its naming conventions for link flags. This patch changes all uses of LINKFLAGS to LINK_FLAGS, for consistency with cmake's LINK_FLAGS property. This patch should make it easier to search the source code for uses of link flags, as well as providing the benefit of improved style and consistency. Reviewers: compnerd, beanz Subscribers: kubabrecka, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D28506 llvm-svn: 291539
2017-01-10 12:33:04 +08:00
set(extra_link_flags_${libname} ${DARWIN_${os}_LINK_FLAGS} ${LIB_LINK_FLAGS})
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
endif()
[compiler-rt] list_union() is actually an intersect operation. Rename it. Summary: Given: set(T1 a b c) set(T2 b c d) message("T1=${T1}") message("T2=${T2}") list_union(T3 T1 T2) message("T3=${T3}") cmake emitted: T1=a;b;c T2=b;c;d T3=b;c Reviewers: beanz Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16580 llvm-svn: 258916
2016-01-27 17:28:01 +08:00
list_intersect(LIB_ARCHS_${libname} DARWIN_${os}_ARCHS LIB_ARCHS)
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
if(LIB_ARCHS_${libname})
list(APPEND libnames ${libname})
[cmake] By default do not build compiler-rt with PGO Patch by Zhizhou Yang! In his own words: """ Currently compiler-rt doesn't officially support either PGO instrumentation or use PGO profdata to build it. PGO related flags are passed into compiler-rt since rL372209, and causing bugs: 45022, crbug:1018840 This patch adds several checks in compiler-rt to disable PGO related flags and provides a flag to turn on PGO for compiler-rt if needed. """ Differential Revision: https://reviews.llvm.org/D75499
2020-03-10 06:25:41 +08:00
set(extra_cflags_${libname} ${DARWIN_${os}_CFLAGS} ${NO_LTO_FLAGS} ${NO_PGO_FLAGS} ${LIB_CFLAGS})
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
set(output_name_${libname} ${libname}${COMPILER_RT_OS_SUFFIX})
[CMake] Add OBJECT_LIBS option to add_compiler_rt_runtime, and refactored asan call site to use it. Summary: This is one more step to allow us to eliminate platform-specific code from the library CMakeLists files. Subsequent patches will refactor all call sites to use this and other new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12339 llvm-svn: 246047
2015-08-27 02:33:51 +08:00
set(sources_${libname} ${LIB_SOURCES})
format_object_libs(sources_${libname} ${os} ${LIB_OBJECT_LIBS})
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
get_compiler_rt_output_dir(${COMPILER_RT_DEFAULT_TARGET_ARCH} output_dir_${libname})
get_compiler_rt_install_dir(${COMPILER_RT_DEFAULT_TARGET_ARCH} install_dir_${libname})
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
endif()
endforeach()
CMake: Add add_compiler_rt_static_runtime function and use it to build generic compiler-rt libraries llvm-svn: 172977
2013-01-20 21:58:10 +08:00
else()
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
foreach(arch ${LIB_ARCHS})
if(NOT CAN_TARGET_${arch})
message(FATAL_ERROR "Architecture ${arch} can't be targeted")
return()
endif()
Reland "[compiler-rt] Simple crtbegin.o and crtend.o implementation" 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 llvm-svn: 359591
2019-05-01 02:13:22 +08:00
if(type STREQUAL "OBJECT")
set(libname "${name}-${arch}")
set_output_name(output_name_${libname} ${name}${COMPILER_RT_OS_SUFFIX} ${arch})
elseif(type STREQUAL "STATIC")
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
set(libname "${name}-${arch}")
Restore clang_rt library name on i686-android. Summary: Recent changes canonicalized clang_rt library names to refer to "i386" on all x86 targets. Android historically uses i686. This change adds a special case to keep i686 in all clang_rt libraries when targeting Android. Reviewers: hans, mgorny, beanz Subscribers: srhines, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D37278 llvm-svn: 312048
2017-08-30 06:12:31 +08:00
set_output_name(output_name_${libname} ${name} ${arch})
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
else()
set(libname "${name}-dynamic-${arch}")
[compiler-rt] Split cflags and link flags to avoid warnings Summary: The MSVC compiler is complaining about invalid flags. The CFLAGS are passed to the linker (i.e. /Gy-, ...). Reviewers: rnk Subscribers: llvm-commits, kubabrecka, chrisha Differential Revision: http://reviews.llvm.org/D21554 llvm-svn: 273265
2016-06-21 22:46:32 +08:00
set(extra_cflags_${libname} ${TARGET_${arch}_CFLAGS} ${LIB_CFLAGS})
Make cmake link flag naming consistent Summary: The build system was inconsistent in its naming conventions for link flags. This patch changes all uses of LINKFLAGS to LINK_FLAGS, for consistency with cmake's LINK_FLAGS property. This patch should make it easier to search the source code for uses of link flags, as well as providing the benefit of improved style and consistency. Reviewers: compnerd, beanz Subscribers: kubabrecka, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D28506 llvm-svn: 291539
2017-01-10 12:33:04 +08:00
set(extra_link_flags_${libname} ${TARGET_${arch}_LINK_FLAGS} ${LIB_LINK_FLAGS})
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
if(WIN32)
Restore clang_rt library name on i686-android. Summary: Recent changes canonicalized clang_rt library names to refer to "i386" on all x86 targets. Android historically uses i686. This change adds a special case to keep i686 in all clang_rt libraries when targeting Android. Reviewers: hans, mgorny, beanz Subscribers: srhines, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D37278 llvm-svn: 312048
2017-08-30 06:12:31 +08:00
set_output_name(output_name_${libname} ${name}_dynamic ${arch})
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
else()
Restore clang_rt library name on i686-android. Summary: Recent changes canonicalized clang_rt library names to refer to "i386" on all x86 targets. Android historically uses i686. This change adds a special case to keep i686 in all clang_rt libraries when targeting Android. Reviewers: hans, mgorny, beanz Subscribers: srhines, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D37278 llvm-svn: 312048
2017-08-30 06:12:31 +08:00
set_output_name(output_name_${libname} ${name} ${arch})
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
endif()
endif()
[compiler-rt] Don't error out on missing builtins when builting builtins themselves This fixes bootstrapping the builtins when no previous version of them exists after 2fe66bdb2e5fb556e15d4a07158e89ec007c587b. Also fix a whitespace issue in that commit.
2020-05-18 16:04:42 +08:00
if(COMPILER_RT_USE_BUILTINS_LIBRARY AND NOT type STREQUAL "OBJECT" AND
NOT name STREQUAL "clang_rt.builtins")
[compiler-rt] Build with correct ABI (PR38025) Summary: This patch fixes [[ https://bugs.llvm.org/show_bug.cgi?id=38025 | PR38025 ]]: Wrong ABI used when building compiler-rt Differential Revision: https://reviews.llvm.org/D74133
2020-03-28 07:17:52 +08:00
get_compiler_rt_target(${arch} target)
find_compiler_rt_library(builtins ${target} builtins_${libname})
[compiler-rt] Don't error out on missing builtins when builting builtins themselves This fixes bootstrapping the builtins when no previous version of them exists after 2fe66bdb2e5fb556e15d4a07158e89ec007c587b. Also fix a whitespace issue in that commit.
2020-05-18 16:04:42 +08:00
if(builtins_${libname} STREQUAL "NOTFOUND")
[Compiler-rt] Emit error if builtins library cannot be found Since setting COMPILER_RT_USE_BUILTINS_LIBRARY would remove -z,defs flag, missing builtins library would continue to build unnoticed. Explicitly emit an error in such case. Differential Revision: https://reviews.llvm.org/D79470
2020-05-16 11:59:21 +08:00
message(FATAL_ERROR "Cannot find builtins library for the target architecture")
endif()
[compiler-rt] Build with correct ABI (PR38025) Summary: This patch fixes [[ https://bugs.llvm.org/show_bug.cgi?id=38025 | PR38025 ]]: Wrong ABI used when building compiler-rt Differential Revision: https://reviews.llvm.org/D74133
2020-03-28 07:17:52 +08:00
endif()
[CMake] Add OBJECT_LIBS option to add_compiler_rt_runtime, and refactored asan call site to use it. Summary: This is one more step to allow us to eliminate platform-specific code from the library CMakeLists files. Subsequent patches will refactor all call sites to use this and other new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12339 llvm-svn: 246047
2015-08-27 02:33:51 +08:00
set(sources_${libname} ${LIB_SOURCES})
format_object_libs(sources_${libname} ${arch} ${LIB_OBJECT_LIBS})
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
set(libnames ${libnames} ${libname})
[cmake] By default do not build compiler-rt with PGO Patch by Zhizhou Yang! In his own words: """ Currently compiler-rt doesn't officially support either PGO instrumentation or use PGO profdata to build it. PGO related flags are passed into compiler-rt since rL372209, and causing bugs: 45022, crbug:1018840 This patch adds several checks in compiler-rt to disable PGO related flags and provides a flag to turn on PGO for compiler-rt if needed. """ Differential Revision: https://reviews.llvm.org/D75499
2020-03-10 06:25:41 +08:00
set(extra_cflags_${libname} ${TARGET_${arch}_CFLAGS} ${NO_LTO_FLAGS} ${NO_PGO_FLAGS} ${LIB_CFLAGS})
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
get_compiler_rt_output_dir(${arch} output_dir_${libname})
get_compiler_rt_install_dir(${arch} install_dir_${libname})
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
endforeach()
CMake: Add add_compiler_rt_static_runtime function and use it to build generic compiler-rt libraries llvm-svn: 172977
2013-01-20 21:58:10 +08:00
endif()
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
if(NOT libnames)
return()
endif()
if(LIB_PARENT_TARGET)
[CMake] Support component-based installation for runtime libraries This enables targets like "install-ubsan" and "install-asan" to install all associated runtime libraries. llvm-svn: 261700
2016-02-24 05:55:38 +08:00
# If the parent targets aren't created we should create them
if(NOT TARGET ${LIB_PARENT_TARGET})
add_custom_target(${LIB_PARENT_TARGET})
[CMake] Tidy up the organisation of compiler-rt when configured as a standalone build with an IDE (e.g. Xcode) as the generator. Previously the global `USE_FOLDERS` property wasn't set in standalone builds leading to existing settings of FOLDER not being respected. In addition to this there were several targets that appeared at the top level that were not interesting and clustered up the view. These have been changed to be displayed in "Compiler-RT Misc". Now when an Xcode project is generated from a standalone compiler-rt build the project navigator is much less cluttered. The interesting libraries should appear in "Compiler-RT Libraries" in the IDE. Differential Revision: https://reviews.llvm.org/D48378 llvm-svn: 335728
2018-06-27 20:56:34 +08:00
set_target_properties(${LIB_PARENT_TARGET} PROPERTIES
FOLDER "Compiler-RT Misc")
[CMake] Support component-based installation for runtime libraries This enables targets like "install-ubsan" and "install-asan" to install all associated runtime libraries. llvm-svn: 261700
2016-02-24 05:55:38 +08:00
endif()
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
endif()
[CMake] Refactoring add_compiler_rt functions for darwin runtimes. Summary: This patch consolidates add_compiler_rt_osx_static_runtime and add_compiler_rt_darwin_dynamic_runtime into a single new function add_compiler_rt_darwin_runtime. Reviewers: filcab, samsonov, bogner Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12106 llvm-svn: 245317
2015-08-19 01:32:18 +08:00
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
foreach(libname ${libnames})
[compiler-rt] Fix VisualStudio virtual folders layout Summary: This patch is a refactoring of the way cmake 'targets' are grouped. It won't affect non-UI cmake-generators. Clang/LLVM are using a structured way to group targets which ease navigation through Visual Studio UI. The Compiler-RT projects differ from the way Clang/LLVM are grouping targets. This patch doesn't contain behavior changes. Reviewers: kubabrecka, rnk Subscribers: wang0109, llvm-commits, kubabrecka, chrisha Differential Revision: http://reviews.llvm.org/D21952 llvm-svn: 275111
2016-07-12 05:51:56 +08:00
# If you are using a multi-configuration generator we don't generate
[CMake] Support component-based installation for runtime libraries This enables targets like "install-ubsan" and "install-asan" to install all associated runtime libraries. llvm-svn: 261700
2016-02-24 05:55:38 +08:00
# per-library install rules, so we fall back to the parent target COMPONENT
if(CMAKE_CONFIGURATION_TYPES AND LIB_PARENT_TARGET)
set(COMPONENT_OPTION COMPONENT ${LIB_PARENT_TARGET})
else()
set(COMPONENT_OPTION COMPONENT ${libname})
endif()
Reland "[compiler-rt] Simple crtbegin.o and crtend.o implementation" 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 llvm-svn: 359591
2019-05-01 02:13:22 +08:00
if(type STREQUAL "OBJECT")
[compiler-rt] Rework the object build support 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 llvm-svn: 359644
2019-05-01 10:49:45 +08:00
if(CMAKE_C_COMPILER_ID MATCHES Clang AND CMAKE_C_COMPILER_TARGET)
[compiler-rt] Cleanup the --target and --sysroot handling This addresses issue introduced in r359646. llvm-svn: 359650
2019-05-01 13:41:58 +08:00
list(APPEND extra_cflags_${libname} "--target=${CMAKE_C_COMPILER_TARGET}")
[compiler-rt] Pass sysroot and disable pedantic for crtbegin.o/crtend.o These are needed to make bots happy. Differential Revision: https://reviews.llvm.org/D61363 llvm-svn: 359646
2019-05-01 11:30:51 +08:00
endif()
if(CMAKE_SYSROOT)
[compiler-rt] Cleanup the --target and --sysroot handling This addresses issue introduced in r359646. llvm-svn: 359650
2019-05-01 13:41:58 +08:00
list(APPEND extra_cflags_${libname} "--sysroot=${CMAKE_SYSROOT}")
[compiler-rt] Rework the object build support 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 llvm-svn: 359644
2019-05-01 10:49:45 +08:00
endif()
string(REPLACE ";" " " extra_cflags_${libname} "${extra_cflags_${libname}}")
string(REGEX MATCHALL "<[A-Za-z0-9_]*>" substitutions
${CMAKE_C_COMPILE_OBJECT})
set(compile_command_${libname} "${CMAKE_C_COMPILE_OBJECT}")
Use CMAKE_C_COMPILER_ARG1 in compiler invocation 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
2019-05-19 11:29:15 +08:00
[compiler-rt] Rework the object build support 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 llvm-svn: 359644
2019-05-01 10:49:45 +08:00
set(output_file_${libname} ${output_name_${libname}}${CMAKE_C_OUTPUT_EXTENSION})
foreach(substitution ${substitutions})
if(substitution STREQUAL "<CMAKE_C_COMPILER>")
Use CMAKE_C_COMPILER_ARG1 in compiler invocation 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
2019-05-19 11:29:15 +08:00
string(REPLACE "<CMAKE_C_COMPILER>" "${CMAKE_C_COMPILER} ${CMAKE_C_COMPILER_ARG1}"
[compiler-rt] Rework the object build support 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 llvm-svn: 359644
2019-05-01 10:49:45 +08:00
compile_command_${libname} ${compile_command_${libname}})
elseif(substitution STREQUAL "<OBJECT>")
string(REPLACE "<OBJECT>" "${output_dir_${libname}}/${output_file_${libname}}"
compile_command_${libname} ${compile_command_${libname}})
elseif(substitution STREQUAL "<SOURCE>")
string(REPLACE "<SOURCE>" "${sources_${libname}}"
compile_command_${libname} ${compile_command_${libname}})
elseif(substitution STREQUAL "<FLAGS>")
[compiler-rt] Cleanup the --target and --sysroot handling This addresses issue introduced in r359646. llvm-svn: 359650
2019-05-01 13:41:58 +08:00
string(REPLACE "<FLAGS>" "${CMAKE_C_FLAGS} ${extra_cflags_${libname}}"
[compiler-rt] Rework the object build support 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 llvm-svn: 359644
2019-05-01 10:49:45 +08:00
compile_command_${libname} ${compile_command_${libname}})
else()
string(REPLACE "${substitution}" "" compile_command_${libname}
${compile_command_${libname}})
endif()
endforeach()
separate_arguments(compile_command_${libname})
Reland "[compiler-rt] Simple crtbegin.o and crtend.o implementation" 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 llvm-svn: 359591
2019-05-01 02:13:22 +08:00
add_custom_command(
[compiler-rt] Rework the object build support 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 llvm-svn: 359644
2019-05-01 10:49:45 +08:00
OUTPUT ${output_dir_${libname}}/${output_file_${libname}}
COMMAND ${compile_command_${libname}}
Reland "[compiler-rt] Simple crtbegin.o and crtend.o implementation" 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 llvm-svn: 359591
2019-05-01 02:13:22 +08:00
DEPENDS ${sources_${libname}}
[compiler-rt] Rework the object build support 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 llvm-svn: 359644
2019-05-01 10:49:45 +08:00
COMMENT "Building C object ${output_file_${libname}}")
add_custom_target(${libname} DEPENDS ${output_dir_${libname}}/${output_file_${libname}})
install(FILES ${output_dir_${libname}}/${output_file_${libname}}
Reland "[compiler-rt] Simple crtbegin.o and crtend.o implementation" 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 llvm-svn: 359591
2019-05-01 02:13:22 +08:00
DESTINATION ${install_dir_${libname}}
${COMPONENT_OPTION})
else()
add_library(${libname} ${type} ${sources_${libname}})
set_target_compile_flags(${libname} ${extra_cflags_${libname}})
set_target_link_flags(${libname} ${extra_link_flags_${libname}})
set_property(TARGET ${libname} APPEND PROPERTY
COMPILE_DEFINITIONS ${LIB_DEFS})
set_target_output_directories(${libname} ${output_dir_${libname}})
install(TARGETS ${libname}
ARCHIVE DESTINATION ${install_dir_${libname}}
${COMPONENT_OPTION}
LIBRARY DESTINATION ${install_dir_${libname}}
${COMPONENT_OPTION}
RUNTIME DESTINATION ${install_dir_${libname}}
${COMPONENT_OPTION})
endif()
[CMake] Track TSan's dependency on C++ headers TSan relies on C++ headers, so when libc++ is being built as part of the runtimes build, include an explicit dependency on cxx-headers which is the same approach that's already used for other sanitizers. Differential Revision: https://reviews.llvm.org/D88912
2020-10-07 02:32:57 +08:00
if(LIB_DEPS)
add_dependencies(${libname} ${LIB_DEPS})
endif()
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
set_target_properties(${libname} PROPERTIES
OUTPUT_NAME ${output_name_${libname}})
[compiler-rt] Fix VisualStudio virtual folders layout Summary: This patch is a refactoring of the way cmake 'targets' are grouped. It won't affect non-UI cmake-generators. Clang/LLVM are using a structured way to group targets which ease navigation through Visual Studio UI. The Compiler-RT projects differ from the way Clang/LLVM are grouping targets. This patch doesn't contain behavior changes. Reviewers: kubabrecka, rnk Subscribers: wang0109, llvm-commits, kubabrecka, chrisha Differential Revision: http://reviews.llvm.org/D21952 llvm-svn: 275111
2016-07-12 05:51:56 +08:00
set_target_properties(${libname} PROPERTIES FOLDER "Compiler-RT Runtime")
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(LIB_LINK_LIBS)
[CMake] Mark runtime library link libraries as private There's no need to expose these dependencies to consumers. This matches the change made to other runtimes in D57456. Differential Revision: https://reviews.llvm.org/D57873 llvm-svn: 353376
2019-02-07 14:32:09 +08:00
target_link_libraries(${libname} PRIVATE ${LIB_LINK_LIBS})
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()
[compiler-rt] Build with correct ABI (PR38025) Summary: This patch fixes [[ https://bugs.llvm.org/show_bug.cgi?id=38025 | PR38025 ]]: Wrong ABI used when building compiler-rt Differential Revision: https://reviews.llvm.org/D74133
2020-03-28 07:17:52 +08:00
if(builtins_${libname})
target_link_libraries(${libname} PRIVATE ${builtins_${libname}})
endif()
[compiler-rt] Fix library suffixes on windows Summary: Make sure that windows libraries contain the suffixes expected by clang. This is expecially important when compiling the windows builtins with clang, as cmake will use .a as the suffix by default. Reviewers: beanz, compnerd Subscribers: llvm-commits, dberris Differential Revision: https://reviews.llvm.org/D24046 llvm-svn: 280854
2016-09-08 04:32:48 +08:00
if(${type} STREQUAL "SHARED")
[cmake] [compiler-rt] Call llvm_setup_rpath() when adding shared libraries. Clang and llvm already use llvm_setup_rpath(), so this change will help standarize rpath usage across all projects. Differential Revision: https://reviews.llvm.org/D42462 llvm-svn: 323606
2018-01-28 05:14:17 +08:00
if(COMMAND llvm_setup_rpath)
llvm_setup_rpath(${libname})
endif()
[compiler-rt] Fix library suffixes on windows Summary: Make sure that windows libraries contain the suffixes expected by clang. This is expecially important when compiling the windows builtins with clang, as cmake will use .a as the suffix by default. Reviewers: beanz, compnerd Subscribers: llvm-commits, dberris Differential Revision: https://reviews.llvm.org/D24046 llvm-svn: 280854
2016-09-08 04:32:48 +08:00
if(WIN32 AND NOT CYGWIN AND NOT MINGW)
set_target_properties(${libname} PROPERTIES IMPORT_PREFIX "")
set_target_properties(${libname} PROPERTIES IMPORT_SUFFIX ".lib")
endif()
[asan] Add support for running lit tests in the iOS Simulator This patch adds a basic support for running the ASan lit test suite against an iOS Simulator. This is done by generating more lit.site.cfg configurations into subdirectories such as IOSSimI386Config and IOSSimX86_64Config. These test suites are not added into "check-all" or into "check-asan", they have to be run manually. Differential Revision: https://reviews.llvm.org/D31477 llvm-svn: 301443
2017-04-27 02:59:22 +08:00
if(APPLE)
# Ad-hoc sign the dylibs
add_custom_command(TARGET ${libname}
POST_BUILD
COMMAND codesign --sign - $<TARGET_FILE:${libname}>
WORKING_DIRECTORY ${COMPILER_RT_LIBRARY_OUTPUT_DIR}
)
endif()
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
endif()
[CMake] Support component-based installation for runtime libraries This enables targets like "install-ubsan" and "install-asan" to install all associated runtime libraries. llvm-svn: 261700
2016-02-24 05:55:38 +08:00
[compiler-rt] Create install targets for Darwin libraries 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
2019-05-08 03:00:37 +08:00
set(parent_target_arg)
if(LIB_PARENT_TARGET)
set(parent_target_arg PARENT_TARGET ${LIB_PARENT_TARGET})
[CMake] Support component-based installation for runtime libraries This enables targets like "install-ubsan" and "install-asan" to install all associated runtime libraries. llvm-svn: 261700
2016-02-24 05:55:38 +08:00
endif()
[compiler-rt] Create install targets for Darwin libraries 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
2019-05-08 03:00:37 +08:00
add_compiler_rt_install_targets(${libname} ${parent_target_arg})
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
if(APPLE)
set_target_properties(${libname} PROPERTIES
OSX_ARCHITECTURES "${LIB_ARCHS_${libname}}")
endif()
[CMake] Support externalizing debug info on Darwin * Adds COMPILER_RT_EXTERNALIZE_DEBUGINFO option * On Darwin this results in calling dsymutil and strip after linking * This generates an error on non-darwin platforms, matching the LLVM behavior llvm-svn: 254643
2015-12-04 04:08:22 +08:00
if(type STREQUAL "SHARED")
rt_externalize_debuginfo(${libname})
endif()
[CMake] merge add_compiler_rt_runtime and add_compiler_rt_darwin_runtime into a single function Summary: This refactoring moves much of the Apple-specific behavior into a function in AddCompilerRT. The next cleanup patch will remove more of the if(APPLE) checks in the outlying CMakeLists. This patch adds a bunch of new functionality to add_compiler_rt_runtime so that the target names don't need to be reconstructed outside the call. It also updates some of the call sites to exercise the new functionality, but does not update all uses fully. Subsequent patches will further update call sites and move to using the new features. Reviewers: filcab, bogner, kubabrecka, zaks.anna, glider, samsonov Subscribers: beanz, rengolin, llvm-commits Differential Revision: http://reviews.llvm.org/D12292 llvm-svn: 245970
2015-08-26 03:53:09 +08:00
endforeach()
if(LIB_PARENT_TARGET)
[CMake] Fix a typo in add_compiler_rt_library. llvm-svn: 262063
2016-02-27 04:59:40 +08:00
add_dependencies(${LIB_PARENT_TARGET} ${libnames})
[CMake] Refactoring add_compiler_rt functions for darwin runtimes. Summary: This patch consolidates add_compiler_rt_osx_static_runtime and add_compiler_rt_darwin_dynamic_runtime into a single new function add_compiler_rt_darwin_runtime. Reviewers: filcab, samsonov, bogner Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12106 llvm-svn: 245317
2015-08-19 01:32:18 +08:00
endif()
endfunction()
CMake: add functions creating universal runtime libraries for several architectures on OS X and use them in ASan and UBSan build rules llvm-svn: 173011
2013-01-21 16:12:20 +08:00
Fix the cross compilation of unit tests. NFC (second attempt) With COMPILER_RT_INCLUDE_TESTS turned ON and in a cross compiling environment, the unit tests fail to link. This patch does the following changes >Rename COMPILER_RT_TEST_CFLAGS to COMPILER_RT_UNITTEST_CFLAGS to reflect the way it's used. >Add COMPILER_RT_TEST_COMPILER_CFLAGS to COMPILER_RT_UNITTEST_CFLAGS so that cross-compiler would be able to build/compile the unit tests >Add COMPILER_RT_UNITTEST_LINKFLAGS to COMPILER_RT_UNITTEST_CFLAGS so that cross-compiler would be able to link the unit tests (if needed) Differential Revision: http://reviews.llvm.org/D16165 llvm-svn: 257783
2016-01-15 02:18:49 +08:00
# when cross compiling, COMPILER_RT_TEST_COMPILER_CFLAGS help
# in compilation and linking of unittests.
string(REPLACE " " ";" COMPILER_RT_UNITTEST_CFLAGS "${COMPILER_RT_TEST_COMPILER_CFLAGS}")
Make cmake link flag naming consistent Summary: The build system was inconsistent in its naming conventions for link flags. This patch changes all uses of LINKFLAGS to LINK_FLAGS, for consistency with cmake's LINK_FLAGS property. This patch should make it easier to search the source code for uses of link flags, as well as providing the benefit of improved style and consistency. Reviewers: compnerd, beanz Subscribers: kubabrecka, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D28506 llvm-svn: 291539
2017-01-10 12:33:04 +08:00
set(COMPILER_RT_UNITTEST_LINK_FLAGS ${COMPILER_RT_UNITTEST_CFLAGS})
[Sanitizers Win] Move duplicate Windows-specific compiler flags to a common CMake variable Reviewed at http://reviews.llvm.org/D3952 llvm-svn: 209889
2014-05-30 20:42:57 +08:00
CMake: create AddCompilerRT module and implement convenience add_compiler_rt_object_library function llvm-svn: 172826
2013-01-19 00:05:21 +08:00
# Unittests support.
Significantly change the way we build ASan unittests in CMake build tree. Now just-built Clang is used to: 1) compile instrumented sources (as before); 2) compile non-instrumented sources; 3) compile our own instrumented version of googletest; 4) link it all together using -fsanitize=address flag (instead of trying to copy linker behavior in CMake build rules). This makes ASan unittests pretty much self-consistent and independent of other LLVM libraries. llvm-svn: 170541
2012-12-19 20:33:39 +08:00
set(COMPILER_RT_GTEST_PATH ${LLVM_MAIN_SRC_DIR}/utils/unittest/googletest)
LLVM's GoogleTest copy has moved its source code back to the default location, update this reference to reflect that. llvm-svn: 194802
2013-11-15 18:21:15 +08:00
set(COMPILER_RT_GTEST_SOURCE ${COMPILER_RT_GTEST_PATH}/src/gtest-all.cc)
[CMake] Rename the variable llvm-svn: 204602
2014-03-24 21:29:20 +08:00
set(COMPILER_RT_GTEST_CFLAGS
reland [gtest] Fix printing of StringRef and SmallString in assert messages. Renames GTEST_NO_LLVM_RAW_OSTREAM -> GTEST_NO_LLVM_SUPPORT and guards the new features behind it. This reverts commit a063bcf3ef5a879adbe9639a3c187d876eee0e66. llvm-svn: 369527
2019-08-21 21:56:29 +08:00
-DGTEST_NO_LLVM_SUPPORT=1
[ASan/Win] Use clang rather than clang-cl by default for lit tests. Make Windows-only tests explicitly use clang-cl. Reviewed at http://reviews.llvm.org/D3893 llvm-svn: 209719
2014-05-28 16:38:13 +08:00
-DGTEST_HAS_RTTI=0
Significantly change the way we build ASan unittests in CMake build tree. Now just-built Clang is used to: 1) compile instrumented sources (as before); 2) compile non-instrumented sources; 3) compile our own instrumented version of googletest; 4) link it all together using -fsanitize=address flag (instead of trying to copy linker behavior in CMake build rules). This makes ASan unittests pretty much self-consistent and independent of other LLVM libraries. llvm-svn: 170541
2012-12-19 20:33:39 +08:00
-I${COMPILER_RT_GTEST_PATH}/include
LLVM's GoogleTest copy has moved its source code back to the default location, update this reference to reflect that. llvm-svn: 194802
2013-11-15 18:21:15 +08:00
-I${COMPILER_RT_GTEST_PATH}
Significantly change the way we build ASan unittests in CMake build tree. Now just-built Clang is used to: 1) compile instrumented sources (as before); 2) compile non-instrumented sources; 3) compile our own instrumented version of googletest; 4) link it all together using -fsanitize=address flag (instead of trying to copy linker behavior in CMake build rules). This makes ASan unittests pretty much self-consistent and independent of other LLVM libraries. llvm-svn: 170541
2012-12-19 20:33:39 +08:00
)
[XRay][compiler-rt] FDRLogWriter Abstraction Summary: This change introduces an `FDRLogWriter` type which is responsible for serialising metadata and function records to character buffers. This is the first step in a refactoring of the implementation of the FDR runtime to allow for more granular testing of the individual components of the implementation. The main contribution of this change is a means of hiding the details of how specific records are written to a buffer, and for managing the extents of these buffers. We make use of C++ features (templates and some metaprogramming) to reduce repetition in the act of writing out specific kinds of records to the buffer. In this process, we make a number of changes across both LLVM and compiler-rt to allow us to use the `Trace` abstraction defined in the LLVM project in the testing of the runtime implementation. This gives us a closer end-to-end test which version-locks the runtime implementation with the loading implementation in LLVM. We also allow using gmock in compiler-rt unit tests, by adding the requisite definitions in the `AddCompilerRT.cmake` module. We also add the terminfo library detection along with inclusion of the appropriate compiler flags for header include lookup. Finally, we've gone ahead and updated the FDR logging implementation to use the FDRLogWriter for the lowest-level record-writing details. Following patches will isolate the state machine transitions which manage the set-up and tear-down of the buffers we're using in multiple threads. Reviewers: mboerger, eizan Subscribers: mgorny, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D52220 llvm-svn: 342617
2018-09-20 13:22:37 +08:00
# Mocking support.
set(COMPILER_RT_GMOCK_PATH ${LLVM_MAIN_SRC_DIR}/utils/unittest/googlemock)
set(COMPILER_RT_GMOCK_SOURCE ${COMPILER_RT_GMOCK_PATH}/src/gmock-all.cc)
set(COMPILER_RT_GMOCK_CFLAGS
reland [gtest] Fix printing of StringRef and SmallString in assert messages. Renames GTEST_NO_LLVM_RAW_OSTREAM -> GTEST_NO_LLVM_SUPPORT and guards the new features behind it. This reverts commit a063bcf3ef5a879adbe9639a3c187d876eee0e66. llvm-svn: 369527
2019-08-21 21:56:29 +08:00
-DGTEST_NO_LLVM_SUPPORT=1
[XRay][compiler-rt] FDRLogWriter Abstraction Summary: This change introduces an `FDRLogWriter` type which is responsible for serialising metadata and function records to character buffers. This is the first step in a refactoring of the implementation of the FDR runtime to allow for more granular testing of the individual components of the implementation. The main contribution of this change is a means of hiding the details of how specific records are written to a buffer, and for managing the extents of these buffers. We make use of C++ features (templates and some metaprogramming) to reduce repetition in the act of writing out specific kinds of records to the buffer. In this process, we make a number of changes across both LLVM and compiler-rt to allow us to use the `Trace` abstraction defined in the LLVM project in the testing of the runtime implementation. This gives us a closer end-to-end test which version-locks the runtime implementation with the loading implementation in LLVM. We also allow using gmock in compiler-rt unit tests, by adding the requisite definitions in the `AddCompilerRT.cmake` module. We also add the terminfo library detection along with inclusion of the appropriate compiler flags for header include lookup. Finally, we've gone ahead and updated the FDR logging implementation to use the FDRLogWriter for the lowest-level record-writing details. Following patches will isolate the state machine transitions which manage the set-up and tear-down of the buffers we're using in multiple threads. Reviewers: mboerger, eizan Subscribers: mgorny, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D52220 llvm-svn: 342617
2018-09-20 13:22:37 +08:00
-DGTEST_HAS_RTTI=0
-I${COMPILER_RT_GMOCK_PATH}/include
-I${COMPILER_RT_GMOCK_PATH}
)
Fix the cross compilation of unit tests. NFC (second attempt) With COMPILER_RT_INCLUDE_TESTS turned ON and in a cross compiling environment, the unit tests fail to link. This patch does the following changes >Rename COMPILER_RT_TEST_CFLAGS to COMPILER_RT_UNITTEST_CFLAGS to reflect the way it's used. >Add COMPILER_RT_TEST_COMPILER_CFLAGS to COMPILER_RT_UNITTEST_CFLAGS so that cross-compiler would be able to build/compile the unit tests >Add COMPILER_RT_UNITTEST_LINKFLAGS to COMPILER_RT_UNITTEST_CFLAGS so that cross-compiler would be able to link the unit tests (if needed) Differential Revision: http://reviews.llvm.org/D16165 llvm-svn: 257783
2016-01-15 02:18:49 +08:00
append_list_if(COMPILER_RT_DEBUG -DSANITIZER_DEBUG=1 COMPILER_RT_UNITTEST_CFLAGS)
[gtest] Teach the sanitizer's custom gtest compilations to disable a warning that 'gtest-all.cc' directly triggers in the newer 1.8.0 version. This should fix a warning in folks' build and bring a couple of -Werror bots back to life. llvm-svn: 291070
2017-01-05 11:41:41 +08:00
append_list_if(COMPILER_RT_HAS_WCOVERED_SWITCH_DEFAULT_FLAG -Wno-covered-switch-default COMPILER_RT_UNITTEST_CFLAGS)
Reapply "Try enabling -Wsuggest-override again, using add_compile_options instead of add_compile_definitions for disabling it in unittests/ directories." add_compile_options is more sensitive to its location in the file than add_definitions--it only takes effect for sources that are added after it. This updated patch ensures that the add_compile_options is done before adding any source files that depend on it. Using add_definitions caused the flag to be passed to rc.exe on Windows and thus broke Windows builds.
2020-07-23 08:44:52 +08:00
append_list_if(COMPILER_RT_HAS_WSUGGEST_OVERRIDE_FLAG -Wno-suggest-override COMPILER_RT_UNITTEST_CFLAGS)
[Sanitizer] Improve unit tests in COMPILER_RT_DEBUG=ON mode. Propagate -DSANITIZER_DEBUG definition to unit tests. Make sure unit tests depend on compiler-rt headers. llvm-svn: 225298
2015-01-07 04:58:40 +08:00
[ASan/Win] Use clang rather than clang-cl by default for lit tests. Make Windows-only tests explicitly use clang-cl. Reviewed at http://reviews.llvm.org/D3893 llvm-svn: 209719
2014-05-28 16:38:13 +08:00
if(MSVC)
[Sanitizers Win] Move duplicate Windows-specific compiler flags to a common CMake variable Reviewed at http://reviews.llvm.org/D3952 llvm-svn: 209889
2014-05-30 20:42:57 +08:00
# gtest use a lot of stuff marked as deprecated on Windows.
list(APPEND COMPILER_RT_GTEST_CFLAGS -Wno-deprecated-declarations)
[ASan/Win] Use clang rather than clang-cl by default for lit tests. Make Windows-only tests explicitly use clang-cl. Reviewed at http://reviews.llvm.org/D3893 llvm-svn: 209719
2014-05-28 16:38:13 +08:00
endif()
[sanitizers CMake] NFC Refactor the logic for compiling and generating tests into a function. Most CMake configuration under compiler-rt/lib/*/tests have almost-the-same-but-not-quite functions of the form add_X_[unit]tests for compiling and running the tests. Much of the logic is duplicated with minor variations across different sub-folders. This can harm productivity for multiple reasons: For newcomers, resulting CMake files are very large, hard to understand, and hide the intention of the code. Changes for enabling certain architectures end up being unnecessarily large, as they get duplicated across multiple folders. Adding new sub-projects requires more effort than it should, as a developer has to again copy-n-paste the configuration, and it's not even clear from which sub-project it should be copy-n-pasted. With this change the logic of compile-and-generate-a-set-of-tests is extracted into a function, which hopefully makes writing and reading CMake much easier. Differential Revision: https://reviews.llvm.org/D36116 llvm-svn: 310971
2017-08-16 06:56:10 +08:00
# Compile and register compiler-rt tests.
# generate_compiler_rt_tests(<output object files> <test_suite> <test_name>
# <test architecture>
# KIND <custom prefix>
# SUBDIR <subdirectory for testing binary>
# SOURCES <sources to compile>
# RUNTIME <tests runtime to link in>
# CFLAGS <compile-time flags>
# COMPILE_DEPS <compile-time dependencies>
# DEPS <dependencies>
# LINK_FLAGS <flags to use during linking>
# )
function(generate_compiler_rt_tests test_objects test_suite testname arch)
cmake_parse_arguments(TEST "" "KIND;RUNTIME;SUBDIR"
"SOURCES;COMPILE_DEPS;DEPS;CFLAGS;LINK_FLAGS" ${ARGN})
foreach(source ${TEST_SOURCES})
sanitizer_test_compile(
"${test_objects}" "${source}" "${arch}"
KIND ${TEST_KIND}
COMPILE_DEPS ${TEST_COMPILE_DEPS}
DEPS ${TEST_DEPS}
CFLAGS ${TEST_CFLAGS}
)
endforeach()
set(TEST_DEPS ${${test_objects}})
if(NOT "${TEST_RUNTIME}" STREQUAL "")
list(APPEND TEST_DEPS ${TEST_RUNTIME})
list(APPEND "${test_objects}" $<TARGET_FILE:${TEST_RUNTIME}>)
endif()
add_compiler_rt_test(${test_suite} "${testname}" "${arch}"
SUBDIR ${TEST_SUBDIR}
OBJECTS ${${test_objects}}
DEPS ${TEST_DEPS}
Quickfix to the refactoring commit: typo in the link flags variable name. llvm-svn: 310973
2017-08-16 07:22:52 +08:00
LINK_FLAGS ${TEST_LINK_FLAGS}
[sanitizers CMake] NFC Refactor the logic for compiling and generating tests into a function. Most CMake configuration under compiler-rt/lib/*/tests have almost-the-same-but-not-quite functions of the form add_X_[unit]tests for compiling and running the tests. Much of the logic is duplicated with minor variations across different sub-folders. This can harm productivity for multiple reasons: For newcomers, resulting CMake files are very large, hard to understand, and hide the intention of the code. Changes for enabling certain architectures end up being unnecessarily large, as they get duplicated across multiple folders. Adding new sub-projects requires more effort than it should, as a developer has to again copy-n-paste the configuration, and it's not even clear from which sub-project it should be copy-n-pasted. With this change the logic of compile-and-generate-a-set-of-tests is extracted into a function, which hopefully makes writing and reading CMake much easier. Differential Revision: https://reviews.llvm.org/D36116 llvm-svn: 310971
2017-08-16 06:56:10 +08:00
)
set("${test_objects}" "${${test_objects}}" PARENT_SCOPE)
endfunction()
[CMake] Use host compiler to build unittests in standalone mode llvm-svn: 201672
2014-02-19 21:01:03 +08:00
# Link objects into a single executable with COMPILER_RT_TEST_COMPILER,
# using specified link flags. Make executable a part of provided
Significantly change the way we build ASan unittests in CMake build tree. Now just-built Clang is used to: 1) compile instrumented sources (as before); 2) compile non-instrumented sources; 3) compile our own instrumented version of googletest; 4) link it all together using -fsanitize=address flag (instead of trying to copy linker behavior in CMake build rules). This makes ASan unittests pretty much self-consistent and independent of other LLVM libraries. llvm-svn: 170541
2012-12-19 20:33:39 +08:00
# test_suite.
[sanitizers CMake] NFC Refactor the logic for compiling and generating tests into a function. Most CMake configuration under compiler-rt/lib/*/tests have almost-the-same-but-not-quite functions of the form add_X_[unit]tests for compiling and running the tests. Much of the logic is duplicated with minor variations across different sub-folders. This can harm productivity for multiple reasons: For newcomers, resulting CMake files are very large, hard to understand, and hide the intention of the code. Changes for enabling certain architectures end up being unnecessarily large, as they get duplicated across multiple folders. Adding new sub-projects requires more effort than it should, as a developer has to again copy-n-paste the configuration, and it's not even clear from which sub-project it should be copy-n-pasted. With this change the logic of compile-and-generate-a-set-of-tests is extracted into a function, which hopefully makes writing and reading CMake much easier. Differential Revision: https://reviews.llvm.org/D36116 llvm-svn: 310971
2017-08-16 06:56:10 +08:00
# add_compiler_rt_test(<test_suite> <test_name> <arch>
[ASan] Always build shared ASan runtime on Linux. This commit changes the strategy for building shared ASan runtime and the way we test it: - COMPILER_RT_BUILD_SHARED_ASAN CMake option is removed. We now always build shared ASan runtime (it is the default on Android, Windows and Mac, and not the default on Linux and FreeBSD). - Platforms, which use static runtime by default now have "check-asan-dynamic" testsuite. This testsuite contains instrumented unit tests, and ASan lit tests, and runs them with shared ASan runtime. This testsuite is *not* a part of "check-asan" and *not* a part of "check-all", as adding 1000 more test cases, which duplicate existing ones is costly. However, you're welcome to add this command to your buildbot. llvm-svn: 224470
2014-12-18 07:14:01 +08:00
# SUBDIR <subdirectory for binary>
Significantly change the way we build ASan unittests in CMake build tree. Now just-built Clang is used to: 1) compile instrumented sources (as before); 2) compile non-instrumented sources; 3) compile our own instrumented version of googletest; 4) link it all together using -fsanitize=address flag (instead of trying to copy linker behavior in CMake build rules). This makes ASan unittests pretty much self-consistent and independent of other LLVM libraries. llvm-svn: 170541
2012-12-19 20:33:39 +08:00
# OBJECTS <object files>
# DEPS <deps (e.g. runtime libs)>
# LINK_FLAGS <link flags>)
[sanitizers CMake] NFC Refactor the logic for compiling and generating tests into a function. Most CMake configuration under compiler-rt/lib/*/tests have almost-the-same-but-not-quite functions of the form add_X_[unit]tests for compiling and running the tests. Much of the logic is duplicated with minor variations across different sub-folders. This can harm productivity for multiple reasons: For newcomers, resulting CMake files are very large, hard to understand, and hide the intention of the code. Changes for enabling certain architectures end up being unnecessarily large, as they get duplicated across multiple folders. Adding new sub-projects requires more effort than it should, as a developer has to again copy-n-paste the configuration, and it's not even clear from which sub-project it should be copy-n-pasted. With this change the logic of compile-and-generate-a-set-of-tests is extracted into a function, which hopefully makes writing and reading CMake much easier. Differential Revision: https://reviews.llvm.org/D36116 llvm-svn: 310971
2017-08-16 06:56:10 +08:00
function(add_compiler_rt_test test_suite test_name arch)
CMake: Stop using LLVM's custom parse_arguments. NFC Summary: Use CMake's cmake_parse_arguments() instead. It's called in a slightly different way, but supports all our use cases. It's in CMake 2.8.8, which is our minimum supported version. CMake 3.0 doc (roughly the same. No direct link to 2.8.8 doc): http://www.cmake.org/cmake/help/v3.0/module/CMakeParseArguments.html?highlight=cmake_parse_arguments Since I was already changing these calls, I changed ARCH and LIB into ARCHS and LIBS to make it more clear that they're lists of arguments. Reviewers: eugenis, samsonov, beanz Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10529 llvm-svn: 240120
2015-06-19 11:39:24 +08:00
cmake_parse_arguments(TEST "" "SUBDIR" "OBJECTS;DEPS;LINK_FLAGS" "" ${ARGN})
[compiler-rt CMake] CMake refactoring: create directories in helper func. Change macro to a function, move creating test directory into `add_compiler_rt_test`. Differential Revision: https://reviews.llvm.org/D36724 llvm-svn: 310943
2017-08-16 02:32:28 +08:00
set(output_dir ${CMAKE_CURRENT_BINARY_DIR})
[ASan] Always build shared ASan runtime on Linux. This commit changes the strategy for building shared ASan runtime and the way we test it: - COMPILER_RT_BUILD_SHARED_ASAN CMake option is removed. We now always build shared ASan runtime (it is the default on Android, Windows and Mac, and not the default on Linux and FreeBSD). - Platforms, which use static runtime by default now have "check-asan-dynamic" testsuite. This testsuite contains instrumented unit tests, and ASan lit tests, and runs them with shared ASan runtime. This testsuite is *not* a part of "check-asan" and *not* a part of "check-all", as adding 1000 more test cases, which duplicate existing ones is costly. However, you're welcome to add this command to your buildbot. llvm-svn: 224470
2014-12-18 07:14:01 +08:00
if(TEST_SUBDIR)
[compiler-rt CMake] CMake refactoring: create directories in helper func. Change macro to a function, move creating test directory into `add_compiler_rt_test`. Differential Revision: https://reviews.llvm.org/D36724 llvm-svn: 310943
2017-08-16 02:32:28 +08:00
set(output_dir "${output_dir}/${TEST_SUBDIR}")
[ASan] Always build shared ASan runtime on Linux. This commit changes the strategy for building shared ASan runtime and the way we test it: - COMPILER_RT_BUILD_SHARED_ASAN CMake option is removed. We now always build shared ASan runtime (it is the default on Android, Windows and Mac, and not the default on Linux and FreeBSD). - Platforms, which use static runtime by default now have "check-asan-dynamic" testsuite. This testsuite contains instrumented unit tests, and ASan lit tests, and runs them with shared ASan runtime. This testsuite is *not* a part of "check-asan" and *not* a part of "check-all", as adding 1000 more test cases, which duplicate existing ones is costly. However, you're welcome to add this command to your buildbot. llvm-svn: 224470
2014-12-18 07:14:01 +08:00
endif()
[compiler-rt CMake] CMake refactoring: create directories in helper func. Change macro to a function, move creating test directory into `add_compiler_rt_test`. Differential Revision: https://reviews.llvm.org/D36724 llvm-svn: 310943
2017-08-16 02:32:28 +08:00
set(output_dir "${output_dir}/${CMAKE_CFG_INTDIR}")
file(MAKE_DIRECTORY "${output_dir}")
set(output_bin "${output_dir}/${test_name}")
[ASan/Win] Fix PR20944 -- run ASan gtests as part of check-asan on Windows llvm-svn: 226831
2015-01-22 22:54:22 +08:00
if(MSVC)
set(output_bin "${output_bin}.exe")
endif()
[compiler-rt] Fix multi-configuration output paths Summary: When using a multi-configuration build (i.e. MSVC) the output path where libraries are dropped is incorrect. Example: ``` C:\src\llvm\examples>d:\src\llvm\build\Release\bin\clang-cl.exe -fsanitize=address test.cc LINK : fatal error LNK1181: cannot open input file 'd:\src\llvm\build\Release\bin\..\lib\clang\3.9.0\lib\windows\clang_rt.asan-i386.lib' ``` The dropped executable path contains the configuration 'Release': ``` 'd:\src\llvm\build\Release\bin\..\lib\clang\3.9.0\lib\windows\Release\clang_rt.asan-i386.lib' ``` The variable 'RUNTIME_OUTPUT_DIRECTORY' is used to specify the output directory. But CMAKE is appending the current configuration (i.e. Debug, Release). see: https://cmake.org/cmake/help/v3.0/prop_tgt/RUNTIME_OUTPUT_DIRECTORY.html ``` "Multi-configuration generators (VS, Xcode) append a per-configuration subdirectory to the specified directory." ``` To avoid this problem, the configuration specific variable must be set: 'RUNTIME_OUTPUT_DIRECTORY_DEBUG', 'RUNTIME_OUTPUT_DIRECTORY_RELEASE', and so on. Reviewers: ddunbar, chapuni, rnk Subscribers: kubabrecka, llvm-commits Differential Revision: http://reviews.llvm.org/D20261 llvm-svn: 269658
2016-05-16 22:58:07 +08:00
[CMake] Use host compiler to build unittests in standalone mode llvm-svn: 201672
2014-02-19 21:01:03 +08:00
# Use host compiler in a standalone build, and just-built Clang otherwise.
if(NOT COMPILER_RT_STANDALONE_BUILD)
list(APPEND TEST_DEPS clang)
endif()
[sanitizers CMake] NFC Refactor the logic for compiling and generating tests into a function. Most CMake configuration under compiler-rt/lib/*/tests have almost-the-same-but-not-quite functions of the form add_X_[unit]tests for compiling and running the tests. Much of the logic is duplicated with minor variations across different sub-folders. This can harm productivity for multiple reasons: For newcomers, resulting CMake files are very large, hard to understand, and hide the intention of the code. Changes for enabling certain architectures end up being unnecessarily large, as they get duplicated across multiple folders. Adding new sub-projects requires more effort than it should, as a developer has to again copy-n-paste the configuration, and it's not even clear from which sub-project it should be copy-n-pasted. With this change the logic of compile-and-generate-a-set-of-tests is extracted into a function, which hopefully makes writing and reading CMake much easier. Differential Revision: https://reviews.llvm.org/D36116 llvm-svn: 310971
2017-08-16 06:56:10 +08:00
get_target_flags_for_arch(${arch} TARGET_LINK_FLAGS)
list(APPEND TEST_LINK_FLAGS ${TARGET_LINK_FLAGS})
Exclude MSVC to try to unbreak their builds. We have a bad skew between how CMake drives a windows link and how our custom command does. llvm-svn: 208903
2014-05-16 00:33:58 +08:00
# If we're not on MSVC, include the linker flags from CMAKE but override them
# with the provided link flags. This ensures that flags which are required to
# link programs at all are included, but the changes needed for the test
# trump. With MSVC we can't do that because CMake is set up to run link.exe
# when linking, not the compiler. Here, we hack it to use the compiler
# because we want to use -fsanitize flags.
[compiler-rt][CMAKE] Only add cmake link flags in standalone build Only add CMAKE_EXE_LINKER_FLAGS when in a standalone bulid. Or else CMAKE_EXE_LINKER_FLAGS contains flags for build compiler of Clang/llvm. This might not be the same as what the COMPILER_RT_TEST_COMPILER supports. eg: the build compiler use lld linker and we use it to build clang with default ld linker then to be tested clang will complain about lld options like --color-diagnostics. Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D78373
2020-05-15 23:21:49 +08:00
# Only add CMAKE_EXE_LINKER_FLAGS when in a standalone bulid.
# Or else CMAKE_EXE_LINKER_FLAGS contains flags for build compiler of Clang/llvm.
# This might not be the same as what the COMPILER_RT_TEST_COMPILER supports.
# eg: the build compiler use lld linker and we build clang with default ld linker
# then to be tested clang will complain about lld options like --color-diagnostics.
if(NOT MSVC AND COMPILER_RT_STANDALONE_BUILD)
Exclude MSVC to try to unbreak their builds. We have a bad skew between how CMake drives a windows link and how our custom command does. llvm-svn: 208903
2014-05-16 00:33:58 +08:00
set(TEST_LINK_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${TEST_LINK_FLAGS}")
separate_arguments(TEST_LINK_FLAGS)
endif()
[CMake] Fix lld detection after D69685 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
2019-12-28 08:01:03 +08:00
if(NOT COMPILER_RT_STANDALONE_BUILD AND COMPILER_RT_HAS_LLD AND "lld" IN_LIST LLVM_ENABLE_PROJECTS)
[sanitizer] Add lld into dependency of sanitizer_common unittests llvm-svn: 370007
2019-08-27 10:06:34 +08:00
# CMAKE_EXE_LINKER_FLAGS may contain -fuse=lld
# FIXME: -DLLVM_ENABLE_LLD=ON and -DLLVM_ENABLE_PROJECTS without lld case.
list(APPEND TEST_DEPS lld)
endif()
[NFC CMake] Do not relink test targets every time in compiler-rt CMake's add_custom_target is considered to be *always* out of date. This patch changes it to a combination of add_custom_target and add_custom_command which actually tracks dependencies' timestamps. On my machine this reliably saves 6-7 seconds on each test group. This can be a large difference when debugging small tests. Differential Revision: https://reviews.llvm.org/D36912 llvm-svn: 311384
2017-08-22 05:19:13 +08:00
add_custom_command(
OUTPUT "${output_bin}"
COMMAND ${COMPILER_RT_TEST_COMPILER} ${TEST_OBJECTS} -o "${output_bin}"
Significantly change the way we build ASan unittests in CMake build tree. Now just-built Clang is used to: 1) compile instrumented sources (as before); 2) compile non-instrumented sources; 3) compile our own instrumented version of googletest; 4) link it all together using -fsanitize=address flag (instead of trying to copy linker behavior in CMake build rules). This makes ASan unittests pretty much self-consistent and independent of other LLVM libraries. llvm-svn: 170541
2012-12-19 20:33:39 +08:00
${TEST_LINK_FLAGS}
[NFC CMake] Do not relink test targets every time in compiler-rt CMake's add_custom_target is considered to be *always* out of date. This patch changes it to a combination of add_custom_target and add_custom_command which actually tracks dependencies' timestamps. On my machine this reliably saves 6-7 seconds on each test group. This can be a large difference when debugging small tests. Differential Revision: https://reviews.llvm.org/D36912 llvm-svn: 311384
2017-08-22 05:19:13 +08:00
DEPENDS ${TEST_DEPS}
)
add_custom_target(T${test_name} DEPENDS "${output_bin}")
set_target_properties(T${test_name} PROPERTIES FOLDER "Compiler-RT Tests")
[compiler-rt] Fix VisualStudio virtual folders layout Summary: This patch is a refactoring of the way cmake 'targets' are grouped. It won't affect non-UI cmake-generators. Clang/LLVM are using a structured way to group targets which ease navigation through Visual Studio UI. The Compiler-RT projects differ from the way Clang/LLVM are grouping targets. This patch doesn't contain behavior changes. Reviewers: kubabrecka, rnk Subscribers: wang0109, llvm-commits, kubabrecka, chrisha Differential Revision: http://reviews.llvm.org/D21952 llvm-svn: 275111
2016-07-12 05:51:56 +08:00
Significantly change the way we build ASan unittests in CMake build tree. Now just-built Clang is used to: 1) compile instrumented sources (as before); 2) compile non-instrumented sources; 3) compile our own instrumented version of googletest; 4) link it all together using -fsanitize=address flag (instead of trying to copy linker behavior in CMake build rules). This makes ASan unittests pretty much self-consistent and independent of other LLVM libraries. llvm-svn: 170541
2012-12-19 20:33:39 +08:00
# Make the test suite depend on the binary.
[NFC CMake] Do not relink test targets every time in compiler-rt CMake's add_custom_target is considered to be *always* out of date. This patch changes it to a combination of add_custom_target and add_custom_command which actually tracks dependencies' timestamps. On my machine this reliably saves 6-7 seconds on each test group. This can be a large difference when debugging small tests. Differential Revision: https://reviews.llvm.org/D36912 llvm-svn: 311384
2017-08-22 05:19:13 +08:00
add_dependencies(${test_suite} T${test_name})
[compiler-rt CMake] CMake refactoring: create directories in helper func. Change macro to a function, move creating test directory into `add_compiler_rt_test`. Differential Revision: https://reviews.llvm.org/D36724 llvm-svn: 310943
2017-08-16 02:32:28 +08:00
endfunction()
[ASan] create default (empty) ASan blacklist file in resource directory llvm-svn: 182380
2013-05-21 21:48:27 +08:00
[CMake] Assign components and dependencies during add_compiler_rt_resource_file This makes it so that component-based installations will include resource files (i.e. blacklists). My next patch will add support for component-based installations. llvm-svn: 261699
2016-02-24 05:50:39 +08:00
macro(add_compiler_rt_resource_file target_name file_name component)
[ASan] create default (empty) ASan blacklist file in resource directory llvm-svn: 182380
2013-05-21 21:48:27 +08:00
set(src_file "${CMAKE_CURRENT_SOURCE_DIR}/${file_name}")
Reland "Install resource files into a share/ directory" Currently these files are being installed into a root installation directory, but this triggers an error when the installation directory is set to an empty string which is often the case when DESTDIR is used to control the installation destination. Differential Revision: https://reviews.llvm.org/D41673 llvm-svn: 322451
2018-01-14 11:43:14 +08:00
set(dst_file "${COMPILER_RT_OUTPUT_DIR}/share/${file_name}")
[CMake] Make sure add_compiler_rt_resource_file doesn't do unnecessary work llvm-svn: 202356
2014-02-27 15:22:59 +08:00
add_custom_command(OUTPUT ${dst_file}
DEPENDS ${src_file}
[ASan] create default (empty) ASan blacklist file in resource directory llvm-svn: 182380
2013-05-21 21:48:27 +08:00
COMMAND ${CMAKE_COMMAND} -E copy_if_different ${src_file} ${dst_file}
[CMake] Make sure add_compiler_rt_resource_file doesn't do unnecessary work llvm-svn: 202356
2014-02-27 15:22:59 +08:00
COMMENT "Copying ${file_name}...")
add_custom_target(${target_name} DEPENDS ${dst_file})
[ASan] create default (empty) ASan blacklist file in resource directory llvm-svn: 182380
2013-05-21 21:48:27 +08:00
# Install in Clang resource directory.
[CMake] Assign components and dependencies during add_compiler_rt_resource_file This makes it so that component-based installations will include resource files (i.e. blacklists). My next patch will add support for component-based installations. llvm-svn: 261699
2016-02-24 05:50:39 +08:00
install(FILES ${file_name}
Reland "Install resource files into a share/ directory" Currently these files are being installed into a root installation directory, but this triggers an error when the installation directory is set to an empty string which is often the case when DESTDIR is used to control the installation destination. Differential Revision: https://reviews.llvm.org/D41673 llvm-svn: 322451
2018-01-14 11:43:14 +08:00
DESTINATION ${COMPILER_RT_INSTALL_PATH}/share
[CMake] Assign components and dependencies during add_compiler_rt_resource_file This makes it so that component-based installations will include resource files (i.e. blacklists). My next patch will add support for component-based installations. llvm-svn: 261699
2016-02-24 05:50:39 +08:00
COMPONENT ${component})
add_dependencies(${component} ${target_name})
[compiler-rt] Fix VisualStudio virtual folders layout Summary: This patch is a refactoring of the way cmake 'targets' are grouped. It won't affect non-UI cmake-generators. Clang/LLVM are using a structured way to group targets which ease navigation through Visual Studio UI. The Compiler-RT projects differ from the way Clang/LLVM are grouping targets. This patch doesn't contain behavior changes. Reviewers: kubabrecka, rnk Subscribers: wang0109, llvm-commits, kubabrecka, chrisha Differential Revision: http://reviews.llvm.org/D21952 llvm-svn: 275111
2016-07-12 05:51:56 +08:00
set_target_properties(${target_name} PROPERTIES FOLDER "Compiler-RT Misc")
[ASan] create default (empty) ASan blacklist file in resource directory llvm-svn: 182380
2013-05-21 21:48:27 +08:00
endmacro()
[asan] Install asan_device_setup to bin/ when targetting Android. asan_device_setup is a utility that prepares a device to run code built with ASan. Essentially, it installs ASan runtime library into the system. For this reason, it has to be at a predictable relative path from the runtime library itself. We also plan to distribute this utility, packaged with runtime library and maybe llvm-symbolizer, to the users. llvm-svn: 202362
2014-02-27 16:41:40 +08:00
macro(add_compiler_rt_script name)
set(dst ${COMPILER_RT_EXEC_OUTPUT_DIR}/${name})
set(src ${CMAKE_CURRENT_SOURCE_DIR}/${name})
add_custom_command(OUTPUT ${dst}
DEPENDS ${src}
COMMAND ${CMAKE_COMMAND} -E copy_if_different ${src} ${dst}
COMMENT "Copying ${name}...")
add_custom_target(${name} DEPENDS ${dst})
install(FILES ${dst}
PERMISSIONS OWNER_READ OWNER_WRITE OWNER_EXECUTE GROUP_READ GROUP_EXECUTE WORLD_READ WORLD_EXECUTE
DESTINATION ${COMPILER_RT_INSTALL_PATH}/bin)
endmacro(add_compiler_rt_script src name)
[CMake] Use ExternalProject to build MSan-ified version of libcxx for unit tests. This change lets MSan rely on libcxx's own build system instead of manually compiling its sources and setting up all the necessary compile flags. It would also simplify compiling libcxx with another sanitizers (in particular, TSan). The tricky part is to make sure libcxx is reconfigured/rebuilt when Clang or MSan runtime library is changed. "clobber" step used in this patch works well for me, but it's possible it would break for other configurations - will watch the buildbots. llvm-svn: 208451
2014-05-10 06:11:03 +08:00
# Builds custom version of libc++ and installs it in <prefix>.
# Can be used to build sanitized versions of libc++ for running unit tests.
# add_custom_libcxx(<name> <prefix>
# DEPS <list of build deps>
Reland "[Fuzzer] Parametrize add_custom_libcxx" add_custom_libcxx uses the just built compiler and installs the built libc++, e.g. for testing, neither of which is desirable in case of Fuzzer where the libc++ should be built using the host compiler and it's only linked into the libFuzzer and should never be installed. This change introduces additional arguments to add_custom_libcxx to allow parametrizing its behavior. Differential Revision: https://reviews.llvm.org/D42330 llvm-svn: 323054
2018-01-21 09:01:53 +08:00
# CFLAGS <list of compile flags>
# USE_TOOLCHAIN)
[CMake] Use ExternalProject to build MSan-ified version of libcxx for unit tests. This change lets MSan rely on libcxx's own build system instead of manually compiling its sources and setting up all the necessary compile flags. It would also simplify compiling libcxx with another sanitizers (in particular, TSan). The tricky part is to make sure libcxx is reconfigured/rebuilt when Clang or MSan runtime library is changed. "clobber" step used in this patch works well for me, but it's possible it would break for other configurations - will watch the buildbots. llvm-svn: 208451
2014-05-10 06:11:03 +08:00
macro(add_custom_libcxx name prefix)
[CMake] Support runtimes and monorepo layouts when looking for libcxx This also slightly refactors the code that's checking the directory presence which allows eliminating one unnecessary variable. Differential Revision: https://reviews.llvm.org/D40637 llvm-svn: 320446
2017-12-12 09:20:52 +08:00
if(NOT COMPILER_RT_LIBCXX_PATH)
[CMake] Use ExternalProject to build MSan-ified version of libcxx for unit tests. This change lets MSan rely on libcxx's own build system instead of manually compiling its sources and setting up all the necessary compile flags. It would also simplify compiling libcxx with another sanitizers (in particular, TSan). The tricky part is to make sure libcxx is reconfigured/rebuilt when Clang or MSan runtime library is changed. "clobber" step used in this patch works well for me, but it's possible it would break for other configurations - will watch the buildbots. llvm-svn: 208451
2014-05-10 06:11:03 +08:00
message(FATAL_ERROR "libcxx not found!")
endif()
[compiler-rt] Build custom libcxx with libcxxabi This changes add_custom_libcxx to also build libcxxabi and merges the two into a static and hermetic library. There are multiple advantages: 1) The resulting libFuzzer doesn't expose C++ internals and looks like a plain C library. 2) We don't have to manually link in libstdc++ to provide cxxabi. 3) The sanitizer tests cannot interfere with an installed version of libc++.so in LD_LIBRARY_PATH. Differential Revision: https://reviews.llvm.org/D58013 llvm-svn: 354212
2019-02-17 20:16:20 +08:00
if(NOT COMPILER_RT_LIBCXXABI_PATH)
message(FATAL_ERROR "libcxxabi not found!")
endif()
[CMake] Use ExternalProject to build MSan-ified version of libcxx for unit tests. This change lets MSan rely on libcxx's own build system instead of manually compiling its sources and setting up all the necessary compile flags. It would also simplify compiling libcxx with another sanitizers (in particular, TSan). The tricky part is to make sure libcxx is reconfigured/rebuilt when Clang or MSan runtime library is changed. "clobber" step used in this patch works well for me, but it's possible it would break for other configurations - will watch the buildbots. llvm-svn: 208451
2014-05-10 06:11:03 +08:00
Reland "[Fuzzer] Parametrize add_custom_libcxx" add_custom_libcxx uses the just built compiler and installs the built libc++, e.g. for testing, neither of which is desirable in case of Fuzzer where the libc++ should be built using the host compiler and it's only linked into the libFuzzer and should never be installed. This change introduces additional arguments to add_custom_libcxx to allow parametrizing its behavior. Differential Revision: https://reviews.llvm.org/D42330 llvm-svn: 323054
2018-01-21 09:01:53 +08:00
cmake_parse_arguments(LIBCXX "USE_TOOLCHAIN" "" "DEPS;CFLAGS;CMAKE_ARGS" ${ARGN})
[CMake] Use ExternalProject to build MSan-ified version of libcxx for unit tests. This change lets MSan rely on libcxx's own build system instead of manually compiling its sources and setting up all the necessary compile flags. It would also simplify compiling libcxx with another sanitizers (in particular, TSan). The tricky part is to make sure libcxx is reconfigured/rebuilt when Clang or MSan runtime library is changed. "clobber" step used in this patch works well for me, but it's possible it would break for other configurations - will watch the buildbots. llvm-svn: 208451
2014-05-10 06:11:03 +08:00
Reland "[Fuzzer] Parametrize add_custom_libcxx" add_custom_libcxx uses the just built compiler and installs the built libc++, e.g. for testing, neither of which is desirable in case of Fuzzer where the libc++ should be built using the host compiler and it's only linked into the libFuzzer and should never be installed. This change introduces additional arguments to add_custom_libcxx to allow parametrizing its behavior. Differential Revision: https://reviews.llvm.org/D42330 llvm-svn: 323054
2018-01-21 09:01:53 +08:00
if(LIBCXX_USE_TOOLCHAIN)
set(compiler_args -DCMAKE_C_COMPILER=${COMPILER_RT_TEST_COMPILER}
-DCMAKE_CXX_COMPILER=${COMPILER_RT_TEST_CXX_COMPILER})
[CMake] Don't set <PROJECT>_STANDALONE_BUILD We shouldn't be treating runtimes builds as standalone builds since we have enough of the context loaded into the runtimes environment. Differential Revision: https://reviews.llvm.org/D57992 llvm-svn: 353601
2019-02-09 11:06:56 +08:00
if(NOT COMPILER_RT_STANDALONE_BUILD AND NOT RUNTIMES_BUILD)
[Fuzzer] Avoid the unnecessary rebuild of the custom libc++ This changes the add_custom_libcxx macro to resemble the llvm_ExternalProject_Add. The primary motivation is to avoid unnecessary libFuzzer rebuilds that are being done on every Ninja/Make invocation. The libc++ should be only rebuilt whenever the libc++ source itself changes. Differential Revision: https://reviews.llvm.org/D43213 llvm-svn: 326921
2018-03-08 02:14:09 +08:00
set(toolchain_deps $<TARGET_FILE:clang>)
set(force_deps DEPENDS $<TARGET_FILE:clang>)
Reland "[Fuzzer] Parametrize add_custom_libcxx" add_custom_libcxx uses the just built compiler and installs the built libc++, e.g. for testing, neither of which is desirable in case of Fuzzer where the libc++ should be built using the host compiler and it's only linked into the libFuzzer and should never be installed. This change introduces additional arguments to add_custom_libcxx to allow parametrizing its behavior. Differential Revision: https://reviews.llvm.org/D42330 llvm-svn: 323054
2018-01-21 09:01:53 +08:00
endif()
[sanitizer] Pass the CMake compiler to custom libc++ build This addresses the error introduced in r323054 on some bots. llvm-svn: 323061
2018-01-21 11:22:22 +08:00
else()
set(compiler_args -DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
-DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER})
Reland "[Fuzzer] Parametrize add_custom_libcxx" add_custom_libcxx uses the just built compiler and installs the built libc++, e.g. for testing, neither of which is desirable in case of Fuzzer where the libc++ should be built using the host compiler and it's only linked into the libFuzzer and should never be installed. This change introduces additional arguments to add_custom_libcxx to allow parametrizing its behavior. Differential Revision: https://reviews.llvm.org/D42330 llvm-svn: 323054
2018-01-21 09:01:53 +08:00
endif()
[Fuzzer] Avoid the unnecessary rebuild of the custom libc++ This changes the add_custom_libcxx macro to resemble the llvm_ExternalProject_Add. The primary motivation is to avoid unnecessary libFuzzer rebuilds that are being done on every Ninja/Make invocation. The libc++ should be only rebuilt whenever the libc++ source itself changes. Differential Revision: https://reviews.llvm.org/D43213 llvm-svn: 326921
2018-03-08 02:14:09 +08:00
set(STAMP_DIR ${prefix}-stamps/)
set(BINARY_DIR ${prefix}-bins/)
add_custom_target(${name}-clear
COMMAND ${CMAKE_COMMAND} -E remove_directory ${BINARY_DIR}
COMMAND ${CMAKE_COMMAND} -E remove_directory ${STAMP_DIR}
COMMENT "Clobbering ${name} build and stamp directories"
USES_TERMINAL
)
[CMake] Tidy up the organisation of compiler-rt when configured as a standalone build with an IDE (e.g. Xcode) as the generator. Previously the global `USE_FOLDERS` property wasn't set in standalone builds leading to existing settings of FOLDER not being respected. In addition to this there were several targets that appeared at the top level that were not interesting and clustered up the view. These have been changed to be displayed in "Compiler-RT Misc". Now when an Xcode project is generated from a standalone compiler-rt build the project navigator is much less cluttered. The interesting libraries should appear in "Compiler-RT Libraries" in the IDE. Differential Revision: https://reviews.llvm.org/D48378 llvm-svn: 335728
2018-06-27 20:56:34 +08:00
set_target_properties(${name}-clear PROPERTIES FOLDER "Compiler-RT Misc")
[Fuzzer] Avoid the unnecessary rebuild of the custom libc++ This changes the add_custom_libcxx macro to resemble the llvm_ExternalProject_Add. The primary motivation is to avoid unnecessary libFuzzer rebuilds that are being done on every Ninja/Make invocation. The libc++ should be only rebuilt whenever the libc++ source itself changes. Differential Revision: https://reviews.llvm.org/D43213 llvm-svn: 326921
2018-03-08 02:14:09 +08:00
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${name}-clobber-stamp
DEPENDS ${LIBCXX_DEPS} ${toolchain_deps}
COMMAND ${CMAKE_COMMAND} -E touch ${BINARY_DIR}/CMakeCache.txt
COMMAND ${CMAKE_COMMAND} -E touch ${STAMP_DIR}/${name}-mkdir
COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_CURRENT_BINARY_DIR}/${name}-clobber-stamp
COMMENT "Clobbering bootstrap build and stamp directories"
)
add_custom_target(${name}-clobber
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${name}-clobber-stamp)
[CMake] Tidy up the organisation of compiler-rt when configured as a standalone build with an IDE (e.g. Xcode) as the generator. Previously the global `USE_FOLDERS` property wasn't set in standalone builds leading to existing settings of FOLDER not being respected. In addition to this there were several targets that appeared at the top level that were not interesting and clustered up the view. These have been changed to be displayed in "Compiler-RT Misc". Now when an Xcode project is generated from a standalone compiler-rt build the project navigator is much less cluttered. The interesting libraries should appear in "Compiler-RT Libraries" in the IDE. Differential Revision: https://reviews.llvm.org/D48378 llvm-svn: 335728
2018-06-27 20:56:34 +08:00
set_target_properties(${name}-clobber PROPERTIES FOLDER "Compiler-RT Misc")
[Fuzzer] Avoid the unnecessary rebuild of the custom libc++ This changes the add_custom_libcxx macro to resemble the llvm_ExternalProject_Add. The primary motivation is to avoid unnecessary libFuzzer rebuilds that are being done on every Ninja/Make invocation. The libc++ should be only rebuilt whenever the libc++ source itself changes. Differential Revision: https://reviews.llvm.org/D43213 llvm-svn: 326921
2018-03-08 02:14:09 +08:00
Reland "Passthrough additional flags to custom libcxx CMake build" This is needed when we're cross-compiling compiler-rt. Differential Revision: https://reviews.llvm.org/D47834 llvm-svn: 334570
2018-06-13 13:32:22 +08:00
set(PASSTHROUGH_VARIABLES
CMAKE_C_COMPILER_TARGET
CMAKE_CXX_COMPILER_TARGET
[compiler-rt] Support for passing through linker flags to libc++ build This may be needed when cross-compiling to certain platforms. Differential Revision: https://reviews.llvm.org/D54027 llvm-svn: 346063
2018-11-03 09:38:26 +08:00
CMAKE_SHARED_LINKER_FLAGS
CMAKE_MODULE_LINKER_FLAGS
CMAKE_EXE_LINKER_FLAGS
Reland "Passthrough additional flags to custom libcxx CMake build" This is needed when we're cross-compiling compiler-rt. Differential Revision: https://reviews.llvm.org/D47834 llvm-svn: 334570
2018-06-13 13:32:22 +08:00
CMAKE_INSTALL_PREFIX
CMAKE_MAKE_PROGRAM
CMAKE_LINKER
CMAKE_AR
CMAKE_RANLIB
CMAKE_NM
CMAKE_OBJCOPY
CMAKE_OBJDUMP
CMAKE_STRIP
CMAKE_SYSROOT
CMAKE_SYSTEM_NAME)
foreach(variable ${PASSTHROUGH_VARIABLES})
[compiler-rt] Support for passing through linker flags to libc++ build This may be needed when cross-compiling to certain platforms. Differential Revision: https://reviews.llvm.org/D54027 llvm-svn: 346063
2018-11-03 09:38:26 +08:00
get_property(is_value_set CACHE ${variable} PROPERTY VALUE SET)
if(${is_value_set})
get_property(value CACHE ${variable} PROPERTY VALUE)
list(APPEND CMAKE_PASSTHROUGH_VARIABLES -D${variable}=${value})
Reland "Passthrough additional flags to custom libcxx CMake build" This is needed when we're cross-compiling compiler-rt. Differential Revision: https://reviews.llvm.org/D47834 llvm-svn: 334570
2018-06-13 13:32:22 +08:00
endif()
endforeach()
[compiler-rt] Pass CMake C and C++ flags to the custom libc++ When building the custom libc++ that's used by libFuzzer as well as MSan and TSan tests, passthrough the C and C++ flags that were passed to the compiler-rt CMake build. These may be needed to successfuly compile the library on a particular platform. Differential Revision: https://reviews.llvm.org/D53862 llvm-svn: 345788
2018-11-01 06:40:25 +08:00
string(REPLACE ";" " " LIBCXX_C_FLAGS "${LIBCXX_CFLAGS}")
get_property(C_FLAGS CACHE CMAKE_C_FLAGS PROPERTY VALUE)
set(LIBCXX_C_FLAGS "${LIBCXX_C_FLAGS} ${C_FLAGS}")
string(REPLACE ";" " " LIBCXX_CXX_FLAGS "${LIBCXX_CFLAGS}")
get_property(CXX_FLAGS CACHE CMAKE_CXX_FLAGS PROPERTY VALUE)
set(LIBCXX_CXX_FLAGS "${LIBCXX_CXX_FLAGS} ${CXX_FLAGS}")
[CMake] Fix Libc++ Modules build. When building the dylib, the C++ headers are fundamentally non-module. They require special versions of the headers in order to provide C++03 and legacy ABI definitions. This causes ODR issues when modules are enabled during both the build and the usage of the libc++ headers. This patch fixes the build error by disabling modules when building the libc++ sources. llvm-svn: 334220
2018-06-08 03:57:43 +08:00
[CMake] Use ExternalProject to build MSan-ified version of libcxx for unit tests. This change lets MSan rely on libcxx's own build system instead of manually compiling its sources and setting up all the necessary compile flags. It would also simplify compiling libcxx with another sanitizers (in particular, TSan). The tricky part is to make sure libcxx is reconfigured/rebuilt when Clang or MSan runtime library is changed. "clobber" step used in this patch works well for me, but it's possible it would break for other configurations - will watch the buildbots. llvm-svn: 208451
2014-05-10 06:11:03 +08:00
ExternalProject_Add(${name}
[Fuzzer] Avoid the unnecessary rebuild of the custom libc++ This changes the add_custom_libcxx macro to resemble the llvm_ExternalProject_Add. The primary motivation is to avoid unnecessary libFuzzer rebuilds that are being done on every Ninja/Make invocation. The libc++ should be only rebuilt whenever the libc++ source itself changes. Differential Revision: https://reviews.llvm.org/D43213 llvm-svn: 326921
2018-03-08 02:14:09 +08:00
DEPENDS ${name}-clobber ${LIBCXX_DEPS}
[CMake] Use ExternalProject to build MSan-ified version of libcxx for unit tests. This change lets MSan rely on libcxx's own build system instead of manually compiling its sources and setting up all the necessary compile flags. It would also simplify compiling libcxx with another sanitizers (in particular, TSan). The tricky part is to make sure libcxx is reconfigured/rebuilt when Clang or MSan runtime library is changed. "clobber" step used in this patch works well for me, but it's possible it would break for other configurations - will watch the buildbots. llvm-svn: 208451
2014-05-10 06:11:03 +08:00
PREFIX ${prefix}
[compiler-rt] Build custom libcxx with libcxxabi This changes add_custom_libcxx to also build libcxxabi and merges the two into a static and hermetic library. There are multiple advantages: 1) The resulting libFuzzer doesn't expose C++ internals and looks like a plain C library. 2) We don't have to manually link in libstdc++ to provide cxxabi. 3) The sanitizer tests cannot interfere with an installed version of libc++.so in LD_LIBRARY_PATH. Differential Revision: https://reviews.llvm.org/D58013 llvm-svn: 354212
2019-02-17 20:16:20 +08:00
SOURCE_DIR ${COMPILER_RT_SOURCE_DIR}/cmake/Modules/CustomLibcxx
[Fuzzer] Avoid the unnecessary rebuild of the custom libc++ This changes the add_custom_libcxx macro to resemble the llvm_ExternalProject_Add. The primary motivation is to avoid unnecessary libFuzzer rebuilds that are being done on every Ninja/Make invocation. The libc++ should be only rebuilt whenever the libc++ source itself changes. Differential Revision: https://reviews.llvm.org/D43213 llvm-svn: 326921
2018-03-08 02:14:09 +08:00
STAMP_DIR ${STAMP_DIR}
BINARY_DIR ${BINARY_DIR}
Reland "Passthrough additional flags to custom libcxx CMake build" This is needed when we're cross-compiling compiler-rt. Differential Revision: https://reviews.llvm.org/D47834 llvm-svn: 334570
2018-06-13 13:32:22 +08:00
CMAKE_ARGS ${CMAKE_PASSTHROUGH_VARIABLES}
Reland "[Fuzzer] Parametrize add_custom_libcxx" add_custom_libcxx uses the just built compiler and installs the built libc++, e.g. for testing, neither of which is desirable in case of Fuzzer where the libc++ should be built using the host compiler and it's only linked into the libFuzzer and should never be installed. This change introduces additional arguments to add_custom_libcxx to allow parametrizing its behavior. Differential Revision: https://reviews.llvm.org/D42330 llvm-svn: 323054
2018-01-21 09:01:53 +08:00
${compiler_args}
[Fuzzer] Avoid the unnecessary rebuild of the custom libc++ This changes the add_custom_libcxx macro to resemble the llvm_ExternalProject_Add. The primary motivation is to avoid unnecessary libFuzzer rebuilds that are being done on every Ninja/Make invocation. The libc++ should be only rebuilt whenever the libc++ source itself changes. Differential Revision: https://reviews.llvm.org/D43213 llvm-svn: 326921
2018-03-08 02:14:09 +08:00
-DCMAKE_C_FLAGS=${LIBCXX_C_FLAGS}
-DCMAKE_CXX_FLAGS=${LIBCXX_CXX_FLAGS}
[CMake] Use ExternalProject to build MSan-ified version of libcxx for unit tests. This change lets MSan rely on libcxx's own build system instead of manually compiling its sources and setting up all the necessary compile flags. It would also simplify compiling libcxx with another sanitizers (in particular, TSan). The tricky part is to make sure libcxx is reconfigured/rebuilt when Clang or MSan runtime library is changed. "clobber" step used in this patch works well for me, but it's possible it would break for other configurations - will watch the buildbots. llvm-svn: 208451
2014-05-10 06:11:03 +08:00
-DCMAKE_BUILD_TYPE=Release
[TSan][libdispatch] Enable linking and running of tests on Linux When COMPILER_RT_INTERCEPT_LIBDISPATCH is ON the TSan runtime library now has a dependency on the blocks runtime and libdispatch. Make sure we set all the required linking options. Also add cmake options for specifying additional library paths to instruct the linker where to search for libdispatch and the blocks runtime. This allows us to build TSan runtime with libdispatch support without installing those libraries into default linker library paths. `CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY` is necessary to avoid aborting the build due to failing the link step in CMake's check_c_compiler test. Reviewed By: dvyukov, kubamracek Differential Revision: https://reviews.llvm.org/D59334 llvm-svn: 356281
2019-03-16 01:52:27 +08:00
-DCMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY
[compiler-rt] add_custom_libcxx should pass LLVM_PATH and a C++ compiler Reviewers: samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16681 llvm-svn: 259493
2016-02-02 20:55:28 +08:00
-DLLVM_PATH=${LLVM_MAIN_SRC_DIR}
[Fuzzer] Avoid the unnecessary rebuild of the custom libc++ This changes the add_custom_libcxx macro to resemble the llvm_ExternalProject_Add. The primary motivation is to avoid unnecessary libFuzzer rebuilds that are being done on every Ninja/Make invocation. The libc++ should be only rebuilt whenever the libc++ source itself changes. Differential Revision: https://reviews.llvm.org/D43213 llvm-svn: 326921
2018-03-08 02:14:09 +08:00
-DLLVM_BINARY_DIR=${prefix}
-DLLVM_LIBRARY_OUTPUT_INTDIR=${prefix}/lib
[compiler-rt] Build custom libcxx with libcxxabi This changes add_custom_libcxx to also build libcxxabi and merges the two into a static and hermetic library. There are multiple advantages: 1) The resulting libFuzzer doesn't expose C++ internals and looks like a plain C library. 2) We don't have to manually link in libstdc++ to provide cxxabi. 3) The sanitizer tests cannot interfere with an installed version of libc++.so in LD_LIBRARY_PATH. Differential Revision: https://reviews.llvm.org/D58013 llvm-svn: 354212
2019-02-17 20:16:20 +08:00
-DCOMPILER_RT_LIBCXX_PATH=${COMPILER_RT_LIBCXX_PATH}
-DCOMPILER_RT_LIBCXXABI_PATH=${COMPILER_RT_LIBCXXABI_PATH}
[CMake] Allow passing extra CMake arguments to custom libc++ This can be used to customize the libc++ build. Differential Revision: https://reviews.llvm.org/D41103 llvm-svn: 321299
2017-12-22 04:04:10 +08:00
${LIBCXX_CMAKE_ARGS}
[Fuzzer] Avoid the unnecessary rebuild of the custom libc++ This changes the add_custom_libcxx macro to resemble the llvm_ExternalProject_Add. The primary motivation is to avoid unnecessary libFuzzer rebuilds that are being done on every Ninja/Make invocation. The libc++ should be only rebuilt whenever the libc++ source itself changes. Differential Revision: https://reviews.llvm.org/D43213 llvm-svn: 326921
2018-03-08 02:14:09 +08:00
INSTALL_COMMAND ""
STEP_TARGETS configure build
BUILD_ALWAYS 1
USES_TERMINAL_CONFIGURE 1
USES_TERMINAL_BUILD 1
USES_TERMINAL_INSTALL 1
Reland "[Fuzzer] Parametrize add_custom_libcxx" add_custom_libcxx uses the just built compiler and installs the built libc++, e.g. for testing, neither of which is desirable in case of Fuzzer where the libc++ should be built using the host compiler and it's only linked into the libFuzzer and should never be installed. This change introduces additional arguments to add_custom_libcxx to allow parametrizing its behavior. Differential Revision: https://reviews.llvm.org/D42330 llvm-svn: 323054
2018-01-21 09:01:53 +08:00
EXCLUDE_FROM_ALL TRUE
[msan] Blacklist __gxx_personality_v0. 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
2019-10-30 06:04:43 +08:00
BUILD_BYPRODUCTS "${prefix}/lib/libc++.a" "${prefix}/lib/libc++abi.a"
[CMake] Use ExternalProject to build MSan-ified version of libcxx for unit tests. This change lets MSan rely on libcxx's own build system instead of manually compiling its sources and setting up all the necessary compile flags. It would also simplify compiling libcxx with another sanitizers (in particular, TSan). The tricky part is to make sure libcxx is reconfigured/rebuilt when Clang or MSan runtime library is changed. "clobber" step used in this patch works well for me, but it's possible it would break for other configurations - will watch the buildbots. llvm-svn: 208451
2014-05-10 06:11:03 +08:00
)
[Fuzzer] Avoid the unnecessary rebuild of the custom libc++ This changes the add_custom_libcxx macro to resemble the llvm_ExternalProject_Add. The primary motivation is to avoid unnecessary libFuzzer rebuilds that are being done on every Ninja/Make invocation. The libc++ should be only rebuilt whenever the libc++ source itself changes. Differential Revision: https://reviews.llvm.org/D43213 llvm-svn: 326921
2018-03-08 02:14:09 +08:00
if (CMAKE_GENERATOR MATCHES "Make")
set(run_clean "$(MAKE)" "-C" "${BINARY_DIR}" "clean")
else()
set(run_clean ${CMAKE_COMMAND} --build ${BINARY_DIR} --target clean
[cmake] Change deprecated $<CONFIG> to $<CONFIGURATION>. NFC See rL357338 for a similar change. The informational expression $<CONFIGURATION> has been deprecated since CMake 3.0 llvm-svn: 357348
2019-03-30 22:38:51 +08:00
--config "$<CONFIG>")
[Fuzzer] Avoid the unnecessary rebuild of the custom libc++ This changes the add_custom_libcxx macro to resemble the llvm_ExternalProject_Add. The primary motivation is to avoid unnecessary libFuzzer rebuilds that are being done on every Ninja/Make invocation. The libc++ should be only rebuilt whenever the libc++ source itself changes. Differential Revision: https://reviews.llvm.org/D43213 llvm-svn: 326921
2018-03-08 02:14:09 +08:00
endif()
[CMake] Use ExternalProject to build MSan-ified version of libcxx for unit tests. This change lets MSan rely on libcxx's own build system instead of manually compiling its sources and setting up all the necessary compile flags. It would also simplify compiling libcxx with another sanitizers (in particular, TSan). The tricky part is to make sure libcxx is reconfigured/rebuilt when Clang or MSan runtime library is changed. "clobber" step used in this patch works well for me, but it's possible it would break for other configurations - will watch the buildbots. llvm-svn: 208451
2014-05-10 06:11:03 +08:00
[Fuzzer] Avoid the unnecessary rebuild of the custom libc++ This changes the add_custom_libcxx macro to resemble the llvm_ExternalProject_Add. The primary motivation is to avoid unnecessary libFuzzer rebuilds that are being done on every Ninja/Make invocation. The libc++ should be only rebuilt whenever the libc++ source itself changes. Differential Revision: https://reviews.llvm.org/D43213 llvm-svn: 326921
2018-03-08 02:14:09 +08:00
ExternalProject_Add_Step(${name} clean
COMMAND ${run_clean}
COMMENT "Cleaning ${name}..."
DEPENDEES configure
Reland "[Fuzzer] Parametrize add_custom_libcxx" add_custom_libcxx uses the just built compiler and installs the built libc++, e.g. for testing, neither of which is desirable in case of Fuzzer where the libc++ should be built using the host compiler and it's only linked into the libFuzzer and should never be installed. This change introduces additional arguments to add_custom_libcxx to allow parametrizing its behavior. Differential Revision: https://reviews.llvm.org/D42330 llvm-svn: 323054
2018-01-21 09:01:53 +08:00
${force_deps}
[Fuzzer] Avoid the unnecessary rebuild of the custom libc++ This changes the add_custom_libcxx macro to resemble the llvm_ExternalProject_Add. The primary motivation is to avoid unnecessary libFuzzer rebuilds that are being done on every Ninja/Make invocation. The libc++ should be only rebuilt whenever the libc++ source itself changes. Differential Revision: https://reviews.llvm.org/D43213 llvm-svn: 326921
2018-03-08 02:14:09 +08:00
WORKING_DIRECTORY ${BINARY_DIR}
EXCLUDE_FROM_MAIN 1
USES_TERMINAL 1
[CMake] Use ExternalProject to build MSan-ified version of libcxx for unit tests. This change lets MSan rely on libcxx's own build system instead of manually compiling its sources and setting up all the necessary compile flags. It would also simplify compiling libcxx with another sanitizers (in particular, TSan). The tricky part is to make sure libcxx is reconfigured/rebuilt when Clang or MSan runtime library is changed. "clobber" step used in this patch works well for me, but it's possible it would break for other configurations - will watch the buildbots. llvm-svn: 208451
2014-05-10 06:11:03 +08:00
)
[Fuzzer] Avoid the unnecessary rebuild of the custom libc++ This changes the add_custom_libcxx macro to resemble the llvm_ExternalProject_Add. The primary motivation is to avoid unnecessary libFuzzer rebuilds that are being done on every Ninja/Make invocation. The libc++ should be only rebuilt whenever the libc++ source itself changes. Differential Revision: https://reviews.llvm.org/D43213 llvm-svn: 326921
2018-03-08 02:14:09 +08:00
ExternalProject_Add_StepTargets(${name} clean)
if(LIBCXX_USE_TOOLCHAIN)
add_dependencies(${name}-clean ${name}-clobber)
set_target_properties(${name}-clean PROPERTIES
SOURCES ${CMAKE_CURRENT_BINARY_DIR}/${name}-clobber-stamp)
endif()
[CMake] Use ExternalProject to build MSan-ified version of libcxx for unit tests. This change lets MSan rely on libcxx's own build system instead of manually compiling its sources and setting up all the necessary compile flags. It would also simplify compiling libcxx with another sanitizers (in particular, TSan). The tricky part is to make sure libcxx is reconfigured/rebuilt when Clang or MSan runtime library is changed. "clobber" step used in this patch works well for me, but it's possible it would break for other configurations - will watch the buildbots. llvm-svn: 208451
2014-05-10 06:11:03 +08:00
endmacro()
[CMake] Support externalizing debug info on Darwin * Adds COMPILER_RT_EXTERNALIZE_DEBUGINFO option * On Darwin this results in calling dsymutil and strip after linking * This generates an error on non-darwin platforms, matching the LLVM behavior llvm-svn: 254643
2015-12-04 04:08:22 +08:00
function(rt_externalize_debuginfo name)
if(NOT COMPILER_RT_EXTERNALIZE_DEBUGINFO)
return()
endif()
[CMake] Provide the ability to skip stripping when generating dSYMs For debugging it is useful to be able to generate dSYM files but not strip the executables. This change adds the ability to skip stripping by setting COMPILER_RT_EXTERNALIZE_DEBUGINFO_SKIP_STRIP=On. llvm-svn: 265057
2016-04-01 05:17:19 +08:00
if(NOT COMPILER_RT_EXTERNALIZE_DEBUGINFO_SKIP_STRIP)
set(strip_command COMMAND xcrun strip -Sl $<TARGET_FILE:${name}>)
endif()
[CMake] Support externalizing debug info on Darwin * Adds COMPILER_RT_EXTERNALIZE_DEBUGINFO option * On Darwin this results in calling dsymutil and strip after linking * This generates an error on non-darwin platforms, matching the LLVM behavior llvm-svn: 254643
2015-12-04 04:08:22 +08:00
if(APPLE)
if(CMAKE_CXX_FLAGS MATCHES "-flto"
OR CMAKE_CXX_FLAGS_${uppercase_CMAKE_BUILD_TYPE} MATCHES "-flto")
set(lto_object ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${name}-lto.o)
[CMake] set_target_properties doesn't append link flags This fixes a bug I introduced in r254643. llvm-svn: 254658
2015-12-04 06:52:22 +08:00
set_property(TARGET ${name} APPEND_STRING PROPERTY
[CMake] CMake calls to set_property with APPEND string need to have a leading space. llvm-svn: 254660
2015-12-04 06:56:21 +08:00
LINK_FLAGS " -Wl,-object_path_lto -Wl,${lto_object}")
[CMake] Support externalizing debug info on Darwin * Adds COMPILER_RT_EXTERNALIZE_DEBUGINFO option * On Darwin this results in calling dsymutil and strip after linking * This generates an error on non-darwin platforms, matching the LLVM behavior llvm-svn: 254643
2015-12-04 04:08:22 +08:00
endif()
add_custom_command(TARGET ${name} POST_BUILD
COMMAND xcrun dsymutil $<TARGET_FILE:${name}>
[CMake] Provide the ability to skip stripping when generating dSYMs For debugging it is useful to be able to generate dSYM files but not strip the executables. This change adds the ability to skip stripping by setting COMPILER_RT_EXTERNALIZE_DEBUGINFO_SKIP_STRIP=On. llvm-svn: 265057
2016-04-01 05:17:19 +08:00
${strip_command})
[CMake] Support externalizing debug info on Darwin * Adds COMPILER_RT_EXTERNALIZE_DEBUGINFO option * On Darwin this results in calling dsymutil and strip after linking * This generates an error on non-darwin platforms, matching the LLVM behavior llvm-svn: 254643
2015-12-04 04:08:22 +08:00
else()
message(FATAL_ERROR "COMPILER_RT_EXTERNALIZE_DEBUGINFO isn't implemented for non-darwin platforms!")
endif()
endfunction()
Allow compiler-rt test targets to work with multi-config CMake generators Multi-config CMake generators need lit to be able to resolve paths of artifacts from previous build steps at lit time, rather than expect them to be fully resolved at CMake time as they may contain the build mode. Differential Revision: https://reviews.llvm.org/D38471 llvm-svn: 318037
2017-11-13 20:57:54 +08:00
# Configure lit configuration files, including compiler-rt specific variables.
function(configure_compiler_rt_lit_site_cfg input output)
set_llvm_build_mode()
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
get_compiler_rt_output_dir(${COMPILER_RT_DEFAULT_TARGET_ARCH} output_dir)
Allow compiler-rt test targets to work with multi-config CMake generators Multi-config CMake generators need lit to be able to resolve paths of artifacts from previous build steps at lit time, rather than expect them to be fully resolved at CMake time as they may contain the build mode. Differential Revision: https://reviews.llvm.org/D38471 llvm-svn: 318037
2017-11-13 20:57:54 +08:00
string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} COMPILER_RT_RESOLVED_TEST_COMPILER ${COMPILER_RT_TEST_COMPILER})
Support for multiarch runtimes layout This change adds a support for multiarch style runtimes layout, so in addition to the existing layout where runtimes get installed to: lib/clang/$version/lib/$os Clang now allows runtimes to be installed to: lib/clang/$version/$target/lib This also includes libc++, libc++abi and libunwind; today those are assumed to be in Clang library directory built for host, with the new layout it is possible to install libc++, libc++abi and libunwind into the runtime directory built for different targets. The use of new layout is enabled by setting the LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both projects and runtimes layouts. The runtimes CMake build has been further modified to use the new layout when building runtimes for multiple targets. Differential Revision: https://reviews.llvm.org/D45604 llvm-svn: 335809
2018-06-28 11:11:52 +08:00
string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} COMPILER_RT_RESOLVED_LIBRARY_OUTPUT_DIR ${output_dir})
Allow compiler-rt test targets to work with multi-config CMake generators Multi-config CMake generators need lit to be able to resolve paths of artifacts from previous build steps at lit time, rather than expect them to be fully resolved at CMake time as they may contain the build mode. Differential Revision: https://reviews.llvm.org/D38471 llvm-svn: 318037
2017-11-13 20:57:54 +08:00
configure_lit_site_cfg(${input} ${output})
endfunction()