Change the LC_ID_DYLIB of ASan's dynamic libraries on OS X to be set to "@rpath/libclang_rt.asan_osx_dynamic.dylib" and similarly for iossim. Clang driver then sets the "-rpath" to be the real path to where clang currently has the dylib (because clang uses the relative path to its current executable). This means if you move the compiler or install the binary release, -fsanitize=address will link to the proper library.
Reviewed at http://reviews.llvm.org/D6018
llvm-svn: 221278
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
It turned out that we have to bridge more stuff between the executable
and the ASan RTL DLL than just __asan_option_detect_stack_use_after_return.
See PR20918 for more details.
llvm-svn: 217673
There is no reason to have different library names for shared and static
cases on linux. It also breaks Android where we install the shared asan-rt
library into the system and should keep the old name.
This change reverts most of r216380 limiting it to win32 targets only.
llvm-svn: 216533
With this patch, "check-asan" passes all the tests with both MT and MD ASan RTL if you set COMPILER_RT_BUILD_SHARED_ASAN to ON
(PR20214)
llvm-svn: 216447
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
Kuba Brecka