summaryrefslogtreecommitdiffstats
path: root/compiler-rt/cmake
Commit message (Collapse)AuthorAgeFilesLines
...
* [XRay] Clean up XRay build configurationDean Michael Berris2018-09-241-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change spans both LLVM and compiler-rt, where we do the following: - Add XRay to the LLVMBuild system, to allow for distributing the XRay trace loading library along with the LLVM distributions. - Use `llvm-config` better in the compiler-rt XRay implementation, to depend on the potentially already-distributed LLVM XRay library. While this is tested with the standalone compiler-rt build, it does require that the LLVMXRay library (and LLVMSupport as well) are available during the build. In case the static libraries are available, the unit tests will build and work fine. We're still having issues with attempting to use a shared library version of the LLVMXRay library since the shared library might not be accessible from the standard shared library lookup paths. The larger change here is the inclusion of the LLVMXRay library in the distribution, which allows for building tools around the XRay traces and profiles that the XRay runtime already generates. Reviewers: echristo, beanz Subscribers: mgorny, hiraditya, mboerger, llvm-commits Differential Revision: https://reviews.llvm.org/D52349 llvm-svn: 342859
* [XRay][compiler-rt] FDRLogWriter AbstractionDean Michael Berris2018-09-203-2/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "[XRay][compiler-rt] FDRLogWriter Abstraction" and 1 more.Evgeniy Stepanov2018-09-192-24/+0
| | | | | | | | Revert the following 2 commits to fix standalone compiler-rt build: * r342523 [XRay] Detect terminfo library * r342518 [XRay][compiler-rt] FDRLogWriter Abstraction llvm-svn: 342596
* [XRay] Detect terminfo libraryDean Michael Berris2018-09-191-0/+14
| | | | | | | | | Instead of assuming `-ltinfo` works, check whether there's terminfo support on the host where LLVMSupport is compiled. Follow-up to D52220. llvm-svn: 342523
* [XRay][compiler-rt] FDRLogWriter AbstractionDean Michael Berris2018-09-181-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. 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: 342518
* [libFuzzer] Port to WindowsMatt Morehouse2018-08-301-1/+4
| | | | | | | | | | | | | | | | | | | | Summary: Port libFuzzer to windows-msvc. This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well. It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch. It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them. Patch By: metzman Reviewers: morehouse, rnk Reviewed By: morehouse, rnk Subscribers: #sanitizers, delcypher, morehouse, kcc, eraman Differential Revision: https://reviews.llvm.org/D51022 llvm-svn: 341082
* Revert "[libFuzzer] Port to Windows"Matt Morehouse2018-08-291-1/+1
| | | | | | This reverts r340949 due to bot breakage again. llvm-svn: 340954
* [libFuzzer] Port to WindowsMatt Morehouse2018-08-291-1/+1
| | | | | | | | | | | | | | | | | | Summary: Port libFuzzer to windows-msvc. This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well. It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch. It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them. Reviewers: morehouse, rnk Reviewed By: morehouse, rnk Subscribers: #sanitizers, delcypher, morehouse, kcc, eraman Differential Revision: https://reviews.llvm.org/D51022 llvm-svn: 340949
* Revert "[libFuzzer] Port to Windows"Matt Morehouse2018-08-281-1/+1
| | | | | | This reverts commit r340860 due to failing tests. llvm-svn: 340867
* [libFuzzer] Port to WindowsMatt Morehouse2018-08-281-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: Port libFuzzer to windows-msvc. This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well. It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch. It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them. Patch By: metzman Reviewers: morehouse, rnk Reviewed By: morehouse, rnk Subscribers: morehouse, kcc, eraman Differential Revision: https://reviews.llvm.org/D51022 llvm-svn: 340860
* [CMake] Don't parse target triple except for archPetr Hosek2018-08-141-10/+4
| | | | | | | | | | | | | | compiler-rt CMake build currently tries to parse the triple and then put it back together, but doing so inherently tricky, and doing so from CMake is just crazy and currently doesn't handle triples that have more than three components. Fortunatelly, the CMake really only needs the architecture part, which is typically the first component, to construct variants for other architectures. This means we can keep the rest of the triple as is and avoid the parsing altogether. Differential Revision: https://reviews.llvm.org/D50548 llvm-svn: 339701
* [CMake] Fix bug in `add_weak_symbols()` function.Dan Liew2018-08-131-1/+9
| | | | | | | | | | | | | Previously the the `weak_symbols.txt` files could be modified and the build system wouldn't update the link flags automatically. Instead the developer had to know to reconfigure CMake manually. This is now fixed by telling CMake that the file being used to read weak symbols from is a configure-time dependency. Differential Revision: https://reviews.llvm.org/D50059 llvm-svn: 339559
* [macOS] stop generating the libclang_rt.10.4.a library for macOS 10.4Alex Lorenz2018-08-081-14/+0
| | | | | | | | The support for macOS 10.4 has been dropped by Xcode 10. rdar://42876880 llvm-svn: 339277
* [CMake] Allow building builtins standalone out of tree without any ↵Martin Storsjo2018-08-031-35/+39
| | | | | | | | | | llvm-config available This is the same as libcxxabi/libcxx do. Differential Revision: https://reviews.llvm.org/D50134 llvm-svn: 338818
* [profile] Support profiling runtime on FuchsiaPetr Hosek2018-07-251-1/+1
| | | | | | | | | | | | | This ports the profiling runtime on Fuchsia and enables the instrumentation. Unlike on other platforms, Fuchsia doesn't use files to dump the instrumentation data since on Fuchsia, filesystem may not be accessible to the instrumented process. We instead use the data sink to pass the profiling data to the system the same sanitizer runtimes do. Differential Revision: https://reviews.llvm.org/D47208 llvm-svn: 337881
* [CMake] Change the flag to use compiler-rt builtins to booleanPetr Hosek2018-07-151-2/+2
| | | | | | | | | | | | This changes the name and the type to what it was prior to r333037 which matches the name of the flag used in other runtimes: libc++, libc++abi and libunwind. We don't need the type to be a string since there's only binary choice between libgcc and compiler-rt unlike in the case of C++ library where there're multiple options. Differential Revision: https://reviews.llvm.org/D49325 llvm-svn: 337116
* [CMake] Add compiler-rt header files to the list of sources for targetsDan Liew2018-07-102-4/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [scudo] Enable Scudo on PPC64Kostya Kortchinsky2018-07-031-1/+1
| | | | | | | | | | | | | | | | Summary: In conjunction with the clang side change D48833, this will enable Scudo on PPC64. I tested `check-scudo` on a powerpc64le box and everything passes. Reviewers: eugenis, alekseyshl Reviewed By: alekseyshl Subscribers: mgorny, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D48834 llvm-svn: 336213
* Skip building TSan on platforms where there are no 64-bit architectures.Kuba Mracek2018-06-281-1/+5
| | | | llvm-svn: 335873
* Support for multiarch runtimes layoutPetr Hosek2018-06-285-15/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CMake] Tidy up the organisation of compiler-rt when configured as a standaloneDan Liew2018-06-274-2/+16
| | | | | | | | | | | | | | | | | | | 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
* [UBsan] Enable ubsan minimal unit tests on OpenBSDDavid Carlier2018-06-251-1/+4
| | | | | | | | | | | | | OpenBSD needs lld linker for sanitisers. Disabling lint checking as some symbols cannot be defined and block the proper unit tests launch. Reviewers: lebedev.ri, vitalybuka Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D48528 llvm-svn: 335524
* Revert "[CMake] Use a different source depending on C++ support"Jonas Hahnfeld2018-06-172-16/+8
| | | | | | | | | This reverts commit r332924 and followup r332936 silencing a warning. The change breaks the build on x86 if there is no 32-bit version of the C++ libraries, see discussion in https://reviews.llvm.org/D47169. llvm-svn: 334903
* [libFuzzer] [NFC] Support multi-arch and multi-OS building and testingGeorge Karpenkov2018-06-141-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D47296 llvm-svn: 334768
* [compiler-rt] Use CMAKE_LINKER instead of hardcoding ldShoaib Meenai2018-06-131-1/+1
| | | | | | | Respect a custom linker path provided by the user if one is present (otherwise CMAKE_LINKER will have been set to the right value by CMake). llvm-svn: 334654
* [XRay] Set an explicit dependency on libc++ when neededPetr Hosek2018-06-131-2/+6
| | | | | | | | | | | 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
* Reland "Passthrough additional flags to custom libcxx CMake build"Petr Hosek2018-06-131-11/+24
| | | | | | | | This is needed when we're cross-compiling compiler-rt. Differential Revision: https://reviews.llvm.org/D47834 llvm-svn: 334570
* Revert r334458, r334220, r334212, r334139.Matt Morehouse2018-06-121-41/+10
| | | | | | | Reverts changes to AddCompilerRT.cmake due to breakage of http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/. llvm-svn: 334528
* [CMake] Remove -Wno-maybe-uninitialized from passthrough vars.Matt Morehouse2018-06-121-0/+3
| | | | | | | Fixes http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/ buildbot. llvm-svn: 334458
* [CMake] Fix Libc++ Modules build.Eric Fiselier2018-06-071-0/+8
| | | | | | | | | | | | 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
* [CMake] Filter out -z,defs when building custom libc++Petr Hosek2018-06-071-3/+7
| | | | | | | | | -z,defs is incompatible with sanitizers so we need to filter it out from the linker flags before passing them to the libc++ build. Differential Revision: https://reviews.llvm.org/D47865 llvm-svn: 334212
* [CMake] Passthrough additional flags to custom libcxx CMake buildPetr Hosek2018-06-061-11/+27
| | | | | | | | This is needed when we're cross-compiling compiler-rt. Differential Revision: https://reviews.llvm.org/D47834 llvm-svn: 334139
* [libFuzzer] Fix a typo in CMake configuration.George Karpenkov2018-05-241-1/+1
| | | | | | | | | NFC now when libFuzzer supports only one architecture, will stop being NFC after multiple architectures are supported. Differential Revision: https://reviews.llvm.org/D47283 llvm-svn: 333239
* Revert "[cmake] [ARM] Check if VFP is supported before including any VFP ↵Azharuddin Mohammed2018-05-241-6/+0
| | | | | | | | builtins" This reverts commit 2a10f5da5acb1b51d0a2ecf13dca0bf1de859db2. llvm-svn: 333232
* [cmake] [ARM] Check if VFP is supported before including any VFP builtinsAzharuddin Mohammed2018-05-241-0/+6
| | | | | | | | | | | | | | | | | | | Summary: rL325492 disables FPU features when using soft floating point (-mfloat-abi=soft), which is used internally when building for armv7. This causes errors with builtins that utililize VFP instructions. With this change we first check if VFP is enabled (by checking if the preprocessor macro __VFP_FP__ is defined) before including such builtins. Reviewers: rengolin, samsonov, compnerd, smeenai, javed.absar, peter.smith Reviewed By: peter.smith Subscribers: peter.smith, mgorny, kristof.beyls, chrib, llvm-commits Differential Revision: https://reviews.llvm.org/D47217 llvm-svn: 333216
* [CMake] Support builtins as Clang default rtlib in compiler-rtPetr Hosek2018-05-221-4/+5
| | | | | | | | | | | | | Use compiler-rt builtins when selected as default Clang rtlib and avoid explicitly passing -rtlib= flag to avoid the "argument unused during compilation" warning. This is a partial alternative to D47094 that does not rely on compiler runtime checks. Differential Revision: https://reviews.llvm.org/D47115 llvm-svn: 333037
* [CMake] Support libc++ as Clang default stdlib in compiler-rtPetr Hosek2018-05-221-0/+1
| | | | | | | | | | | | Use libc++ when selected as default Clang stdlib and avoid checking C++ compiler when using the in-tree version of libc++. This is a partial alternative to D47094 that does not rely on compiler runtime checks. Differential Revision: https://reviews.llvm.org/D47100 llvm-svn: 333010
* [CMake] Silence unused variable warning in compiler checkPetr Hosek2018-05-221-2/+2
| | | | | | This is breaking the compiler check. llvm-svn: 332936
* [CMake] Use a different source depending on C++ supportPetr Hosek2018-05-222-8/+16
| | | | | | | | | | | When using system C++ library, assume we have a working C++ compiler and try to compile a complete C++ program. When using in tree C++ library, only check the C compiler since the C++ library likely won't have been built yet at time of running the check. Differential Revision: https://reviews.llvm.org/D47169 llvm-svn: 332924
* Revert "[CMake] Reland "Make simple source used for CMake checks a C file""Petr Hosek2018-05-212-5/+1
| | | | | | | This reverts commit rCRT332679 which doesn't quite work and will be replaced by D47100 and D47115 which is a cleaner solution. llvm-svn: 332871
* Revert r332683 & r332684 relating to compiler runtime checksReid Kleckner2018-05-182-64/+4
| | | | | | | r332683 passes flags to the compiler without first checking if they are supported. llvm-svn: 332754
* [CMake] Use <UNIX|WINDOWS>_COMMAND with separate_argumentsPetr Hosek2018-05-181-1/+5
| | | | | | NATIVE_COMMAND is only available since CMake 3.9. llvm-svn: 332684
* [CMake] Detect the compiler runtime and standard libraryPetr Hosek2018-05-182-4/+60
| | | | | | | | | | Rather then requiring the user to specify runtime the compiler runtime and C++ standard library, or trying to guess them which is error-prone, use auto-detection by parsing the compiler link output. Differential Revision: https://reviews.llvm.org/D46857 llvm-svn: 332683
* [CMake] Reland "Make simple source used for CMake checks a C file"Petr Hosek2018-05-172-1/+5
| | | | | | | | | | | The source being compiled is plain C, but using .cc extension forces it to be compiled as C++ which requires a working C++ compiler including C++ library which may not be the case when we're building compiler-rt together with libcxx as part of runtimes build. Differential Revision: https://reviews.llvm.org/D47031 llvm-svn: 332679
* [CMake] Cleanup find_compiler_rt_library function [NFC]Petr Hosek2018-05-171-3/+2
| | | | | | Rename the output variable and remove the unnecessary set call. llvm-svn: 332661
* Add basic compiler-rt builtins support for hexagon.Sid Manning2018-05-092-1/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D46364 llvm-svn: 331881
* Revert "[CMake] Make simple source used for CMake checks a C file"Petr Hosek2018-04-271-1/+1
| | | | | | | This reverts commit r331003 which breaks sanitizer bots because of missing 32-bit libstdc++ library. llvm-svn: 331009
* [CMake] Make simple source used for CMake checks a C filePetr Hosek2018-04-261-1/+1
| | | | | | | | | | | The source being compiled is plain C, but using .cc extension forces it to be compiled as C++ which requires a working C++ compiler including C++ library which may not be the case when we're building compiler-rt together with libcxx as part of runtimes build. Differential Revision: https://reviews.llvm.org/D46152 llvm-svn: 331003
* Revert "[cmake] Remove duplicate command line options from build"Aaron Smith2018-04-111-2/+2
| | | | | | | | 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
* [cmake] Remove duplicate command line options from buildAaron Smith2018-04-111-2/+2
| | | | | | | | | | | | | CMAKE_CXX_FLAGS was added twice to the command line. This causes the command line options to be doubled which works until it doesn't as not all options can be specified twice. For example, clang-cl foo.c /GS- /GS- -mllvm -small-loop-cost=1 -mllvm -small-loop-cost=1 clang (LLVM option parsing): for the -small-loop-cost option: may only occur zero or one times! llvm-svn: 329817
OpenPOWER on IntegriCloud