The new parser is a lot stricter about syntax, reports unrecognized
flags, and will make it easier to implemented some of the planned features.
llvm-svn: 226169
Use unwind.h to get the declarations for unwinding interfaces. This header is
already provided by clang and gcc, so this adds no additional dependencies for
building the builtins library. It avoids the duplication which may drift over
time though.
llvm-svn: 225990
LLVM_LIBDIR_SUFFIX variable to one place in the cmake file.
This is all that I had to do to get everything from compiler-rt working
for me, but there may be more work required if folks are relying on more
parts of compiler-rt. Notably, I'm mostly using it for the sanitizers.
llvm-svn: 224928
The compiler-rt CMake build currently uses -gline-tables-only for all builds. While this makes the debugger correctly map source files, debugging of the runtime libraries in general is pretty tough, because you don't see any local variables, parameters, etc. Let's allow emitting full debugging info by setting COMPILER_RT_DEBUG=ON.
Reviewed at http://reviews.llvm.org/D6764
llvm-svn: 224749
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
The minimal fake SDK was very useful in allowing us to build for all
Darwin platforms without needing access to the real SDKs, but it did
not support building any of the sanitizer runtimes. It's important to
fix that. As a consequence, if you don't have the iOS SDKs installed,
we will now skip building the iOS-specific libclang_rt libraries.
rdar://problem/18825276
llvm-svn: 221621
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
* 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
If we don't reset CMAKE_OSX_DEPLOYMENT_TARGET, it will end up in
CFLAGS together with the -mmacosx-version-min that we set,
and the compiler errors about the conflict.
llvm-svn: 215468
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
Re-apply SVN r213684 which was reverted in SVN r213724 since it broke the
build bots. Add a tweak to enable inclusion of the assembly sources in
standalone build as well.
Original commit message:
This patch address the PR20360. The CMake assembler build system
ignores the .S assembly files in builtins library build. This patch
fixes the issue.
llvm-svn: 214013
Summary: The patch supports both the clang cross-compiler and native compiler
Patch by Kumar Sukhani <Kumar.Sukhani@imgtec.com>
Test Plan:
Kumar had the following asan test results when compiled on a MIPS board:
Expected Passes : 96
Expected Failures : 2
Unsupported Tests : 84
Unexpected Passes : 4
Unexpected Failures: 19
The list of unexpected failures can be found in the review.
Reviewers: kcc, petarj, dsanders
Reviewed By: kcc
Subscribers: farazs, kcc, llvm-commits
Differential Revision: http://reviews.llvm.org/D4208
llvm-svn: 211587
No longer need to set ANDROID if COMPILER_RT_TEST_TARGET_TRIPLE is
arm-linux-androideabi.
No need to set ANDROID_COMMON_FLAGS. These flags are already in
CMAKE_CXX_FLAGS which are used in try_compile().
llvm-svn: 210053
You can expect the sanitizers to be built under any of the following conditions:
1) CMAKE_C_COMPILER is GCC built to cross-compile to ARM
2) CMAKE_C_COMPILER is Clang built to cross-compile to ARM (ARM is default target)
3) CMAKE_C_COMPILER is Clang and CMAKE_C_FLAGS contains -target and --sysroot
Differential Revision: http://reviews.llvm.org/D3794
llvm-svn: 209835
The patch adds better target_triple and target_arch defaults for lit tests,
which allows us to XFAIL tests based on architecture.
Was:
target_triple = LLVM_DEFAULT_TARGET_TRIPLE
target_arch = HOST_ARCH
Now:
target_triple = COMPILER_RT_TEST_TARGET_TRIPLE
, otherwise LLVM_DEFAULT_TARGET_TRIPLE
target_arch = first item in COMPILER_RT_TEST_TARGET_TRIPLE
Differential Revision: http://reviews.llvm.org/D3855
llvm-svn: 209256
Add the test infrastructure for testing lib/profile and a single test.
This initial commit only enables the tests on Darwin, but they'll be
enabled on Linux soon after.
<rdar://problem/16458307>
llvm-svn: 205256
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
For now, use both keywords, INTERFACE and PRIVATE via the variable,
- ${cmake_2_8_12_INTERFACE}
- ${cmake_2_8_12_PRIVATE}
They could be cleaned up when we introduce 2.8.12.
llvm-svn: 202239
1) Depend on llvm-config (configured in LLVM_CONFIG_PATH) to
get necessary LLVM source/binary directories.
2) Add basic support for running lit tests (check-xsan commands).
For now this "support" is far from what we want:
* unit tests are not built currently.
* lit tests use Clang/compiler-rt from LLVM build directory,
not the host compiler or just-built compiler-rt libraries.
We should make a choice on the way we intend ti run compiler-rt lit testsuite:
a) use either Clang from LLVM build tree, or the host compiler.
b) use either just-built runtimes, or the runtimes shipped with the
host compiler.
Using just-built runtimes is tricky - we have to know where to put them, so that
Clang/GCC driver would pick them up (and not overwrite the existing runtimes).
Using a host compiler instead of Clang from LLVM build tree will give us a chance to
run lit tests under GCC (which already has support for several sanitizers).
That is, I tend to make the following choice: if we're in a standalone compiler-rt
build, use host compiler with its set of runtime libraries to run lit tests.
This will effectively decouple "make compiler-rt" and "make check-compiler-rt" in
a standalone build - the latter wouldn't invoke the former. Note that if we decide
to fix LLVM/Clang/compiler-rt build system so that it would configure/build
compiler-rt with just-built Clang (as we do in Makefile-based build), this will not
be a problem - we can add a dependency to ensure that clang/compiler-rt are rebuilt
before running compiler-rt tests.
llvm-svn: 201656
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
This change replaces 32- and 64- bit config.in-s with a single config template
that is used to generate both 32 and 64 bits configs as well as the new
arm-android config. Arm-android config is special because it can run tests on
a remote device over adb (android debug bridge).
We replace %clang with a script that run the compiler, upload the result to
the device, and replaces it with another script. The second script runs the
binary on the device and delivers stdout/stderr/exitcode back.
llvm-svn: 201394
This change adds a copy of <ucontext.h> for Android found in google-breakpad
that is missing from the official NDK.
ASan SEGV handler is still disabled by default and can be enabled with
ASAN_OPTIONS=handle_segv.
llvm-svn: 201084
If the -fno-function-sections flag isn't recognized, the compiler
emits a warning. This isn't enough to cause the check to fail, so we
enable -Werror as well.
llvm-svn: 200753
It breaks when a binary is linked with --gc-sections: parts of sanitizer
interface get thrown away and inaccessible from dlopen-ed libs.
llvm-svn: 200683
Adding the ARM RT sources to the CMake files, and enabling some
sanitizers to also build on ARM. This is far from supported or
production quality, but enabling it to build will get us errors
that we can actually fix.
Having said that, the Compiler-RT and the Asan libraries are
know to work on some variations of ARM.
llvm-svn: 200546
(-Wl,-syslibroot was accidentally overridden by -isysroot from Clang on OSX 10.9)
-isysroot is a Clang/LLVM-GCC-specific option, but hosting libsanitizer for LLVM
with GCC on Darwin shouldn't work anyway, because of the missing blocks support.
llvm-svn: 195132
Summary:
Definitions we use in public sanitizer headers may
slightly conflict with the ones we use in private sanitizer runtimes.
Moreover, we generally forbid to include any system headers (like <stdint.h>)
in sanitizer runtime headers. This leads to inevitable duplication of selected
interface function declarations, but we decided to live with it.
Reviewers: pcc
Reviewed By: pcc
CC: kcc, llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2179
llvm-svn: 194955
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
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
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
This is the first in a sequence of changes designed to eliminate the
libc dependency in sanitizer_common. The main motivation for these
changes is to be able to provide an alternative for the current
interceptor-based technique for instrumenting functions in libc.
In this new technique, we compile libc with instrumentation. This has
the potential advantages of being more accurate than interception and
reducing the amount of custom code required for each libc function.
As a side effect of this, we cannot depend on libc in the sanitizer
runtime due to mutual dependency issues.
This change disables the GCC stack protector, which introduces a libc
dependency and is enabled by default in Ubuntu.
Differential Revision: http://llvm-reviews.chandlerc.com/D755
llvm-svn: 181422
The reason why this simple change is needed is that I am trying to set up a
quick cmake/ninja based buildbot and apple-clang does not support using the
sanitizers currently.
The default behavior follows exactly what was there before implying that no ones
builds should be affected at all.
llvm-svn: 178455
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
This is the first (1/2) part of a change that moves llvm-symbolizer to llvm/tools/, which will allow to build it
with both cmake and configure+make.
llvm-svn: 167722
library.
These headers are intended to be available to user code when built with
AddressSanitizer (or one of the other sanitizer's in the future) to
interface with the runtime library. As such, they form stable external
C interfaces, and the headers shouldn't be located within the
implementation.
I've pulled them out into what seem like fairly obvious locations and
names, but I'm wide open to further bikeshedding of these names and
locations.
I've updated the code and the build system to cope with the new
locations, both CMake and Makefile. Please let me know if this breaks
anyone's build.
The eventual goal is to install these headers along side the Clang
builtin headers when we build the ASan runtime and install it. My
current thinking is to locate them at:
<prefix>/lib/clang/X.Y/include/sanitizer/common_interface_defs.h
<prefix>/lib/clang/X.Y/include/sanitizer/asan_interface.h
<prefix>/lib/clang/X.Y/include/sanitizer/...
But maybe others have different suggestions?
Fixing the style of the #include between these headers at least unblocks
experimentation with installing them as they now should work when
installed in these locations.
llvm-svn: 162822
This hoists most of the CFLAGS into a common variable. It also adds
detection for -Wno-c99-extensions and uses it to silence a pile of
warnings.
Finally, it switches to the proper flag -rdynamic.
With this, the cmake build is warning free on my bootstrap Linux build.
llvm-svn: 162809
just-built Clang binary, and linking them against the just-built ASan
runtime.
This is *very* brittle. I expect it will require tweaking, and I've
pro-actively disabled it on non-Unix builds and on cross-builds.
It is also currently missing dependency edges on GoogleTest header files
and a few other corner cases, but those can be fixed. This is the major
milestone of a mini-bootstrap-like build of the unittest.
llvm-svn: 159255
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
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
Block.h/Block_private.h headers, since clients won't know what to
set. These are moved into runtime.c as appropriate
2) Use cmake checks for CAS builtins, instead of guessing based on GCC
#defines (which aren't set by clang and llvm-gcc anyway)
3) "#pragma mark" isn't supported by FSF gcc, so "#if 0" it out. It
should still show up in IDEs that support it
4) Fix some compiler warnings. GCC 4.3.3 seems super strict about
%p. function pointers can't be cast to void * either.
5) Avoid a warning for apple_versioning.c that "ISO C does not allow
empty files"
llvm-svn: 82504
Evgeniy Stepanov