Summary:
Change the way we use ASan and UBSan together. Instead of keeping two
separate runtimes (libclang_rt.asan and libclang_rt.ubsan), embed UBSan
into ASan and get rid of libclang_rt.ubsan. If UBSan is not supported on
a platform, all UBSan sources are just compiled into dummy empty object
files. UBSan initialization code (e.g. flag parsing) is directly called
from ASan initialization, so we are able to enforce correct
initialization order.
This mirrors the approach we already use for ASan+LSan. This change
doesn't modify the way we use standalone UBSan.
Test Plan: regression test suite
Reviewers: kubabrecka, zaks.anna, rsmith, kcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8646
llvm-svn: 233861
One test case is updated to allow for differences between power and other architectures in behavior when returning from main in certain instances
http://reviews.llvm.org/D8743
llvm-svn: 233813
Passing MSVC-style cflags to the gcc-style clang driver will almost
always end badly. Just translate a couple of simple flags used by the
base CMake cflags like /D, /U, and /O.
llvm-svn: 232219
This reverts commit r229665. It seems that the AArch64 ASAN tests, that
pass on all our internal machines, doesn't like the public buildbot.
Turning this off until we can investigate the public bot for a better
understanding.
llvm-svn: 229739
Prior to this change we built two identical runtimes, named "powerpc64"
and "powerpc64le", while their actual endianness matched the host
endianness.
llvm-svn: 228650
This reverts commit r227966, which turned ASAN on on AArhc64 and may be the
cause of the bots never finishing the check-all. I'll re-apply once we're
sure that bot can cope with it.
llvm-svn: 228023
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
When CMake builds a dynamic library on Windows, the .dll file's location is
determined by the RUNTIME_OUTPUT_DIRECTORY, which we were previously not
setting.
This means for example that clang_rt.asan_dynamic-i386.dll will get built
and installed in the same directory as the corresponding .lib file,
instead of being built in the bin/ directory and not installed at all.
Differential Revision: http://reviews.llvm.org/D6508
llvm-svn: 223387
Summary:
I don't know anything about profiling but it seems to work out of the
box on PowerPC64. At least "make check-profile" works.
A few tests needed tweaking because PowerPC64 IR declares main with
"define signext i32 @main" instead of just "define i32 @main".
This also fixes the asan asan_and_llvm_coverage_test test, which
compiles with -coverage so requires that a profiling version of
libclang_rt has been built.
Reviewers: dexonsmith, kcc, samsonov
Reviewed By: samsonov
Subscribers: samsonov, llvm-commits
Differential Revision: http://reviews.llvm.org/D6233
llvm-svn: 221877
objects with the powerpc64le name. i.e. asan-powerpc64le.a
This change allows those objects to be built.
Differential Revision: http://reviews.llvm.org/D6043
llvm-svn: 221356
C4146: 'unary minus operator applied to unsigned type, result still unsigned'
C4291: ''declaration' : no matching operator delete found; memory will not be freed if initialization throws an exception'
C4800: ''type' : forcing value to bool 'true' or 'false' (performance warning)'
llvm-svn: 220507
cmake/config-ix.cmake: Enabled building of asan for mipsel arch
test/asan/CMakeLists.txt: Enabled testing of asan for mipsel
Patch by Kumar Sukhani
Differential Revision: http://reviews.llvm.org/D5615
llvm-svn: 219496
Makes sure ARM bots don't run AArch64 and vice-versa, since not all
AArch64 systems can run AArch32 and no ARM hardware can run AArch64.
llvm-svn: 219304
Summary:
Changed cmake/config-ix.cmake to add support for different MIPS architectures: mips, mipsel, mips64, mips64el
In profile code there is no target based dependencies, so just enabling mips flag does the work.
Patch by Mohit Bhakkad
Reviewers: dsanders, void, petarj, kcc, samsonov
Reviewed By: samsonov
Subscribers: llvm-commits, farazs, kumarsukhani
Differential Revision: http://reviews.llvm.org/D4880
llvm-svn: 218866
This is needed so we can produce -i686- named libraries for
x86 Android (which is i686-linux-android).
An alternative solution would be keeping the "i386" name internally and
tweaking the OUTPUT_NAME of compiler-rt libraries.
llvm-svn: 218761
* 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
Changed files:
config-ix.cmake: Enabled UBSan for MIPS32
sanitizer_stacktrace.cc: Program counter for MIPS32 is four byte aligned
and a delay slot so subtracted PC by 8 for getting call site address.
cast-overflow.cpp: Added big endian support for this test case.
Patch by Sagar Thakur.
Differential Revision: http://reviews.llvm.org/D4881
llvm-svn: 218519
Summary:
The extra macro definition needs to go into COMPILER_RT_GTEST_CFLAGS
in order to be used for gtests on MSVC2012.
Test Plan: This is part of the fixes necessary for the ASAN tests to pass with MSVC2012.
Reviewers: timurrrr
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5493
llvm-svn: 218464
Summary: This is copied from llvm/utils/unittest/CMakeLists.txt.
Test Plan: This partly enables building ASAN tests with MSVC2012.
Reviewers: timurrrr
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5342
llvm-svn: 217762
a given platform in a top-level CMakeLists.txt to use it both
in lib/ and in test/ subdirectories. Move architecture/platform
checks to config-ix.
llvm-svn: 215247
for sanitizers to pass the C++ compilation and exe linking flags through
from the host CMake configuration. We pass the target flags afterward,
allowing them to trump flags as needed. This is particularly important
when the flags direct Clang, even the just-built-Clang, toward the
standard library, linker, and other tools to use.
llvm-svn: 208896
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
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
Patch by Brad King.
Our add_sanitizer_rt_symbols macro reads the LOCATION property of a
library to compute the location of the "lib<name>.a.syms" file to
generate next to the corresponding "lib<name>.a" library file. CMake
3.0 introduces policy CMP0026 to disallow reading of the LOCATION target
property from non-imported targets in favor of the more powerful
$<TARGET_FILE> generator expression.
Teach add_sanitizer_rt_symbols to use the $<TARGET_FILE> generator
expression to compute the location of the symbols file to generate
with a custom command. CMake 3.0 also adds support for generator
expressions to install(FILES) so use it when available to simplify
installation of the symbols file of the proper configuration.
llvm-svn: 202797
Patch by Brad King.
When using a multi-config generator with CMake, such as for VS or Xcode,
the LOCATION target property value contains a placeholder such as
"$(Configuration)" that is meant for substitution by the native build
tool. The install(FILES) command does not understand this name and will
not install the symbols file correctly when using these generators.
Teach add_sanitizer_rt_symbols to read the more-specific target property
LOCATION_<CONFIG> that has a per-configuration value and no placeholder.
On single-configuration generators (Makefile, Ninja), CMAKE_BUILD_TYPE
contains the name of the one configuration to be built. On multi-config
generators (VS, Xcode), CMAKE_CONFIGURATION_TYPES contains the list of
possible configurations. In the latter case, loop over the configs and
add a configuration-specific install(FILES) rule for each one.
Place the code block inside an if(TRUE) block so it can be made
conditional in a following change without updating indentation.
llvm-svn: 202796
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
This way it gets picked up for all sanitizer libs, both sanitizer_common
and asan. I believe those are the only libs that build with asan.
There should be no need to set the __func__ definition inside
clang_compile.
llvm-svn: 202303
This change allows to build compiler-rt libraries separately from
LLVM/Clang (path to LLVM build directory should be specified at
configure time). Running tests is not yet supported.
llvm-svn: 201647
CMake changes to build the ASan runtime for the iOS simulator. This is a universal library targeting the same architectures as the OSX ASan runtime does, thus the iossim version can't live in the same universal libclang_rt.asan_osx_dynamic.dylib
The difference between the OSX and iossim builds is in the -mios-simulator-version-min and -ios_simulator_version_min flags that tell Clang to compile and link iossim code.
The iossim runtime can only be built on a machine with both Xcode and the iOS Simulator SDK installed. If xcodebuild -version -sdk iphonesimulator Path returns a nonempty path, it is used when compiling and linking the iossim runtime.
llvm-svn: 194199
(1) instrumented, i.e. compiled and linked with -fsanitize=address
(2) not instrumented, compiled w/o -fsanitize=address and linked with ASan runtime statically.
llvm-svn: 190788
This change adds a Python script that is invoked for
the just-built sanitizer runtime to generate the list of exported symbols
passed to the linker. By default, it contains interceptors and sanitizer
interface functions, but can be extended with tool-specific lists.
llvm-svn: 189356
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
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
Dmitry Vyukov