summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/tools/llvm-cfi-verify/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* Make CMakeLists.txt formatting more consistent with the rest of LLVM.Nico Weber2018-05-091-1/+2
| | | | llvm-svn: 331837
* [CMake] Use PRIVATE in target_link_libraries for executablesShoaib Meenai2017-12-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently use target_link_libraries without an explicit scope specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables. Dependencies added in this way apply to both the target and its dependencies, i.e. they become part of the executable's link interface and are transitive. Transitive dependencies generally don't make sense for executables, since you wouldn't normally be linking against an executable. This also causes issues for generating install export files when using LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM library dependencies, which are currently added as interface dependencies. If clang is in the distribution components but the LLVM libraries it depends on aren't (which is a perfectly legitimate use case if the LLVM libraries are being built static and there are therefore no run-time dependencies on them), CMake will complain about the LLVM libraries not being in export set when attempting to generate the install export file for clang. This is reasonable behavior on CMake's part, and the right thing is for LLVM's build system to explicitly use PRIVATE dependencies for executables. Unfortunately, CMake doesn't allow you to mix and match the keyword and non-keyword target_link_libraries signatures for a single target; i.e., if a single call to target_link_libraries for a particular target uses one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must also be updated to use those keywords. This means we must do this change in a single shot. I also fully expect to have missed some instances; I tested by enabling all the projects in the monorepo (except dragonegg), and configuring both with and without shared libraries, on both Darwin and Linux, but I'm planning to rely on the buildbots for other configurations (since it should be pretty easy to fix those). Even after this change, we still have a lot of target_link_libraries calls that don't specify a scope keyword, mostly for shared libraries. I'm thinking about addressing those in a follow-up, but that's a separate change IMO. Differential Revision: https://reviews.llvm.org/D40823 llvm-svn: 319840
* [cfi-verify] Add blacklist parsing for result filtering.Mitch Phillips2017-11-031-0/+1
| | | | | | | | | | | | | | | | | | | | | Adds blacklist parsing behaviour for filtering results into four categories: - Expected Protected: Things that are not in the blacklist and are protected. - Unexpected Protected: Things that are in the blacklist and are protected. - Expected Unprotected: Things that are in the blacklist and are unprotected. - Unexpected Unprotected: Things that are not in the blacklist and are unprotected. now can optionally be invoked with a second command line argument, which specifies the blacklist file that the binary was built with. Current statistics for chromium: Reviewers: vlad.tsyrklevich Subscribers: mgorny, llvm-commits, pcc, kcc Differential Revision: https://reviews.llvm.org/D39525 llvm-svn: 317364
* Fix LLVM_LINK_LLVM_DYLIB=On build of llvm-cfi-verifySam Clegg2017-10-241-1/+0
| | | | | | | | Subscribers: mgorny, aheejin Differential Revision: https://reviews.llvm.org/D39250 llvm-svn: 316493
* Restore the fix rL316059 eliminated by rL316372Serguei Katkov2017-10-241-0/+1
| | | | | | | | | rL316059 fixed the potential build failure when compiling with -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON. rL316372 just reverted the part of the fix, so restore it. llvm-svn: 316422
* Made llvm-cfi-verify not execute unit tests on non-x86 builds.Mitch Phillips2017-10-231-6/+3
| | | | | | | | | | | | | | Patched out from D38427. Reviewers: vlad.tsyrklevich Reviewed By: vlad.tsyrklevich Subscribers: llvm-commits, kcc, pcc, mgorny Differential Revision: https://reviews.llvm.org/D39197 llvm-svn: 316375
* Graph builder implementation.Mitch Phillips2017-10-231-2/+3
| | | | | | | | | | | | | | | | | | Implement a localised graph builder for indirect control flow instructions. Main interface is through GraphBuilder::buildFlowGraph, which will build a flow graph around an indirect CF instruction. Various modifications to FileVerifier are also made to const-expose some members needed for machine code analysis done by the graph builder. Reviewers: vlad.tsyrklevich Reviewed By: vlad.tsyrklevich Subscribers: llvm-commits, kcc, pcc Differential Revision: https://reviews.llvm.org/D38427 llvm-svn: 316372
* Accidently merged an incomplete upstream patch in ↵Mitch Phillips2017-10-231-3/+2
| | | | | | 10e6ee563a6b5ca498f27972ca6dbe6c308f1ac2 - reverting the changes. llvm-svn: 316359
* Patch inMitch Phillips2017-10-231-2/+3
| | | | llvm-svn: 316358
* Statically link llvm-cfi-verify's libraries.Vlad Tsyrklevich2017-10-181-1/+1
| | | | | | | | | | | | | | | | | | | Summary: llvm-cfi-verify (D38379) introduced a potential build failure when compiling with `-DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON`. Specific versions of cmake seem to treat the `add_subdirectory()` rule differently. It seems as if old versions of cmake BFS these rules, adding them to the fringe for expansion later. Newer versions of cmake seem to immediately execute CMakeFiles that are present in this subdirectory. If the subdirectory is expanded through the fringe, the globbing resultant from `llvm_add_implicit_projects()` from `cmake/modules/AddLLVM.cmake:1012` means that `tools/llvm-shlib/CMakeFile.txt` gets executed before `tools/llvm-cfi-verify/lib/CMakeFile.txt`. As the latter CMakeFile adds a new library, this expansion order means that the library files required the unit tests in `unittests/tools/llvm-cfi-verify/` are not present in the dynamic library. This causes unit tests to fail as the required functions can't be found. This change now ensures that the libraries created by `llvm-cfi-verify` are statically linked into the unit tests. As `tools/llvm-cfi-verify/lib` no longer adds anything to `llvm-shlib`, there should be no concern about the order-of-compilation. Reviewers: skatkov, pcc Reviewed By: skatkov, pcc Subscribers: llvm-commits, kcc, pcc, aheejin, vlad.tsyrklevich, mgorny Differential Revision: https://reviews.llvm.org/D39020 llvm-svn: 316059
* [cfi-verify] Fix typo, actually check X86 targetVlad Tsyrklevich2017-10-121-1/+1
| | | | | | | The typo in r315556 disabled the cfi-verify unit tests from building unconditionally, have it correctly check for the X86 target. llvm-svn: 315581
* [cfi-verify] Fix unittest failures w/o x86 targetVlad Tsyrklevich2017-10-121-2/+5
| | | | | | | | The llvm-cfi-verify unit tests fail if LLVM is built without the X86 target, disable the unit tests from being built unless X86 is enabled for now. llvm-svn: 315556
* Reland 'Classify llvm-cfi-verify.'Vlad Tsyrklevich2017-10-111-0/+15
Summary: Move llvm-cfi-verify into a class in preparation for CFI analysis to come. Reviewers: vlad.tsyrklevich Reviewed By: vlad.tsyrklevich Subscribers: mgorny, llvm-commits, pcc, kcc Differential Revision: https://reviews.llvm.org/D38379 llvm-svn: 315504
OpenPOWER on IntegriCloud