This fixes '___asan_init_v4 already defined' errors when linking some of Chromium DLLs.
Looks like one of the DLL is using a .lib produced while linking another DLL and it exploded after r212699.
I'm trying to come up with a small testcase...
llvm-svn: 212815
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: 208609
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
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 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
This change adds ASAN_OPTIONS=start_deactivated=1 flag. When present, ASan will
start in "deactivated" mode, with no heap poisoning, no quarantine, no stack
trace gathering, and minimal redzones. All this features come back when
__asan_init is called for the constructor of an instrumented library.
The primary use case for this feature is Android. Code itself is not
Android-specific, and this patch includes a Linux test for it.
llvm-svn: 199377
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 moves away from creating the symbolizer object and initializing the
external symbolizer as separate steps. Those steps now always take place
together.
Sanitizers with a legacy requirement to specify their own symbolizer path
should use InitSymbolizer to initialize the symbolizer with the desired
path, and GetSymbolizer to access the symbolizer. Sanitizers with no
such requirement (e.g. UBSan) can use GetOrInitSymbolizer with no need for
initialization.
The symbolizer interface has been made thread-safe (as far as I can
tell) by protecting its member functions with mutexes.
Finally, the symbolizer interface no longer relies on weak externals, the
introduction of which was probably a mistake on my part.
Differential Revision: http://llvm-reviews.chandlerc.com/D1985
llvm-svn: 193448
(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
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
Introduce a new object library, RTSanitizerCommonLibc, which will contain
the subset of sanitizer_common with libc dependencies. RTSanitizerCommon
contains the remainder of sanitizer_common, and is intended to have no
libc dependencies. Begin moving code to RTSanitizerCommonLibc, starting
with sanitizer_common.cc, whose libc-dependent portion is moved to
sanitizer_common_libcdep.cc, the first member of the new library.
This split affects the CMake build only. The makefile build continues
to produce the full sanitizer_common library.
llvm-svn: 182118
Now that we have only one dependency on asan_intercepted_functions.h, we can unite that code with the interceptors declarations in asan_interceptors.cc and get rid of asan_intercepted_functions.h
llvm-svn: 175631
This CL drastically simplifies the way we're hooking the memory allocation routines in ASan on Mac by using dylib interposition to replace the main malloc_zone_* functions. This allows us to avoid replacing the default CFAllocator and drop the CF dependency at all.
Committing this patch will result in the static runtime being broken. A follow-up CL will switch ASan to use the dynamic runtime library.
llvm-svn: 173134
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
The goal is to be able to run ASan tests by simply running "make check-asan" command from CMake build tree:
* tests should use fresh clang binary from current build tree.
* tests should use the same RUN-lines syntax as llvm/clang reg tests.
Next steps:
- restricting tests to machines where target is equal to host, i.e. where we can produce working binaries.
- moving AddressSanitizer unit tests to lit as well.
llvm-svn: 161050
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
Add the initial support for building ASan tests.
The first change here is to try to get the CFLAGS to more closely match
those used by the old Makefile. There are probably still goofs here,
ASan folks, your review would be appreciated.
The second big change is to add support for building both
instrumentation based an non-instrumentation based unittests for ASan.
They are built a bit differently from how the old makefiles managed
things. Specifically, there are two binaries, one for the
non-instrumented case, and one for the instrumented case.
Also, the instrumented unit tests rely on the host compiler supporting
AddressSanitizer's intrumentation pass. This is kind-of gross, but
I don't know of a better way yet. I've mailed llvmdev to discuss this
issue.
One big caveat is that the detection logic currently doesn't work. I've
commented it out temporarily as I'd like to get feedback from the ASan
developers, etc.
llvm-svn: 159134
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
Timur Iskhodzhanov