This sets flags and excludes things that aren't working with MSVC yet,
allowing us to build the ASan runtime as part of the cmake build.
Differential Revision: http://llvm-reviews.chandlerc.com/D1525
llvm-svn: 189304
DataFlowSanitizer is a generalised dynamic data flow analysis.
Unlike other Sanitizer tools, this tool is not designed to detect a
specific class of bugs on its own. Instead, it provides a generic
dynamic data flow analysis framework to be used by clients to help
detect application-specific issues within their own code.
Differential Revision: http://llvm-reviews.chandlerc.com/D967
llvm-svn: 187924
ASan, and friends.
This explicitly switches the CompilerRT CMake build to require CMake
version 2.8.8 or newer which provides first-class support for "object"
libraries which consist of a pile of '.o' files -- exactly what is
desired for composing runtime libraries. I've gone ahead and switched to
using this.
I've also added the interception library which I missed initially. And
I've added proper dependencies between the various libraries. With this,
I'm able to build archives for asan that appear to contain all of the
necessary .o files.
The final tweak here is to start setting up the compile flags and macro
defines expected by ASan and its helper libraries. These may not be
entirely correct currently, they're based loosely on my reading of the
old Makefiles. However, they can be tweaked more easily now that they're
wired up properly.
llvm-svn: 159129
to get it working again, two changes were needed:
- I had to give up on glob-based file expansion. This just isn't well
supported by CMake, and until we convince upstream there of its value,
it's not worth dealing with the pain.
- Add the common library as otherwise even ASan won't build.
This now builds again, although the "correctness" of it is a touch
debatable. ;] Specifically, there is no merging of the common runtime
library with the asan runtime library into a single archive file. I'm
not really sure what the best technique is for that, and it may be
influenced by the ongoing discussion about how best to link runtime
libraries.
Note of course that this is still very much WIP. It doesn't entirely
work yet, and remains disabled by the LLVM projects/CMakeLists.txt until
it is in a working state.
llvm-svn: 158811
Some high-level notes:
1) An explicit goal is to support building compiler-rt as a subproject
build, checked out into the projects/compiler-rt directory. There are
many other possible ways of building the code here, but this is
optimized for development on LLVM/Clang/compiler-rt, and incremental
trial and testing of the toolchain.
2) The current support is targeted at Linux. I would love to see this
generalized to other platforms, but for the sake of simplicity in
testing, I'm focusing here first.
Much of this patch was paired with Manuel, and I credit him with the
majority of the work here.
Some important caveats that I'll be working on in subsequent patches:
1) This uses the host compiler rather than using the just-built-clang.
2) Currently only x86 is supported.
3) Currently, none of the tests are built or run.
4) Uses CMake's builtin globbing which doesn't update correctly.
5) This is still turned off from LLVM's CMake build until these issues
are addressed
llvm-svn: 154060
I cannot build any part of this successfully on either Linux or Darwin,
and the replacement is worlds simpler by requiring that this be built as
a subproject of LLVM. If this breaks you for any reason, please let me
know, and let me know what your use case is.
llvm-svn: 154059
Alexey Samsonov