This was already set up for the iOS simulator ASan dylib simulator,
and this change extends that to the other iOS runtime libraries.
This is in preparation for building all those iOS libraries against
the real SDKs instead of the fake SDKs in compiler-rt.
llvm-svn: 221614
Call it "libclang_rt.builtins-<arch>.a" to be consistent
with sanitizers/profile libraries naming. Modify Makefile
and CMake build systems and Clang driver accordingly.
Fixes PR19822.
llvm-svn: 209474
asan_cxx containts replacements for new/delete operators, and should
only be linked in C++ mode. We plan to start building this part
with exception support to make new more standard-compliant.
See https://code.google.com/p/address-sanitizer/issues/detail?id=295
for more details.
llvm-svn: 208610
from (external) compiler-rt build tree into LLVM/Clang build tree in
LLVM_BUILD_EXTERNAL_COMPILER_RT mode.
For instance, running
make asan -j12
in LLVM/Clang build tree will now build Clang, use it to configure
compiler-rt build tree, and invoke "make asan -j12" there. ASan runtime will
be built in the proper location, where Clang driver expects to find it.
Running
make check-asan
will build Clang, use it to configure compiler-rt build tree, build everything
there, and then run "make check-asan" in compiler-rt build tree using just-built
Clang and ASan runtime.
llvm-svn: 204463
With this change, one may set LLVM_BUILD_EXTERNAL_COMPILER_RT option
to build compiler-rt libraries with just-built Clang.
make compiler-rt
in the build tree will build all compiler-rt libraries with just-built Clang
and copy them to the proper location in the Clang resource directory.
make check-compiler-rt
will run the compiler-rt test suite using just-built Clang and runtime
libraries.
The goal is to make LLVM_BUILD_EXTERNAL_COMPILER_RT the default, so that
we can always build compiler-rt libraries with Clang, not the host compiler,
and for all the platforms Clang can target.
llvm-svn: 202367
The soft-float variants of (embedded) libclang_rt only make sense for ARM, so
there's no point in trying to build them if the compiler is only capable of
targeting x86.
llvm-svn: 197033
This builds extra versions of compiler-rt targeting various unhosted targets.
Only built on Darwin since even though they're not iOS or OSX, they share some
quirks.
llvm-svn: 194878
When using the configure build system, the libc++ headers were being
installed in lib/, whereas cmake installs them in include/. Since
include/ makes more sense for headers, we'll make both systems install
headers there.
llvm-svn: 194833
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/D966
llvm-svn: 187925
to build and one had grown out of sync. Put this list in a variable so
this doesn't happen again.
The whole thing here is somewhat suspicious as we don't support 32-bit
environments with a 64-bit bi-arch capable compiler, but none have
complained yet about this so I'm just leaving it alone.
llvm-svn: 184665
* libclang_rt-san-* is sanitizer_common, and is linked in only if no other
sanitizer runtime is present.
* libclang_rt-ubsan-* is the piece of the runtime which doesn't depend on
a C++ ABI library, and is always linked in.
* libclang_rt-ubsan_cxx-* is the piece of the runtime which depends on a
C++ ABI library, and is only linked in when linking a C++ binary.
This change also switches us to using -whole-archive for the ubsan runtime
(which is made possible by the above split), and switches us to only linking
the sanitizer runtime into the main binary and not into DSOs (which is made
possible by using -whole-archive).
The motivation for this is to only link a single copy of sanitizer_common
into any binary. This is becoming important now because we want to share
more state between multiple sanitizers in the same process (for instance,
we want a single shared output mutex).
The Darwin ubsan runtime is unchanged; because we use a DSO there, we don't
need this complexity.
llvm-svn: 177605
This lets one build ASan runtime for ARM/Android by running
make -C tools/clang/runtime/ \
LLVM_ANDROID_TOOLCHAIN_DIR=/path/to/ndk/toolchain
in an existing build tree.
llvm-svn: 166560
Bob Wilson