There is now a more common functionality in the form of called_from_lib suppressions.

llvm-svn: 213057

There are no known usages anymore, so one less thing to support.

llvm-svn: 213056

llvm-svn: 213054

[ASan] Only define macros in asan_init_version.h, move the __asan_init declaration back to asan_interface_internal.h

This fixes the issues we've uncovered after landing r212815.

Reviewed at http://reviews.llvm.org/D4500

llvm-svn: 213053

llvm-svn: 212979

This is a test case for r212815.

llvm-svn: 212959

llvm-svn: 212952

llvm-svn: 212951

llvm-svn: 212944

This is a follow-up to r212807

llvm-svn: 212943

llvm-svn: 212937

This was done by calling __cxa_demangle directly, which is bad
when c++abi library is instrumented. The following line always
contains the demangled name (when running with a symbolizer) anyway.

llvm-svn: 212929

Fixed in r212872.

llvm-svn: 212926

Currently ASan instrumentation pass creates a string with global name
for each instrumented global (to include global names in the error report). Global
name is already mangled at this point, and we may not be able to demangle it
at runtime (e.g. there is no __cxa_demangle on Android).

Instead, create a string with fully qualified global name in Clang, and pass it
to ASan instrumentation pass in llvm.asan.globals metadata. If there is no metadata
for some global, ASan will use the original algorithm.

This fixes https://code.google.com/p/address-sanitizer/issues/detail?id=264.

llvm-svn: 212872

Demangle names of involved globals. Print a more consistent summary line.

llvm-svn: 212857

llvm-svn: 212823

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

llvm-svn: 212809

Reviewed at http://reviews.llvm.org/D4471

llvm-svn: 212807

llvm-svn: 212801

Our versions are not exactly as fast as libc's, and
MSan uses them heavily (even compared to other sanitizers).

This will break if libc version of mem* are instrumented,
but they never are, and if they are, we should be able
to fix it on libc side.

llvm-svn: 212799

llvm-svn: 212798

This is a minor fix to two tsan tests that were expecting the wrong
column information. Now that clang emits column information by default
in its debugging output, the tests had started failing.

llvm-svn: 212779

llvm-svn: 212749

Fast path was never triggered when called from __msan_poison.

llvm-svn: 212715

llvm-svn: 212704

Reviewed at http://reviews.llvm.org/D4459

llvm-svn: 212699

Without some mention of armv6m in a subdirectory of builtins, the make code
doesn't even know that armv6m exists and is something it should be looking for
in the platform-specific Makefiles. This means that none of the functions
listed actually get built and we end up with an almost entirely empty
libclang_rt.a for armv6m.

Unfortunately, the assembly code in the usual arm directory has no hope of
running on armv6m, which only supports Thumb-1 (not even ARM mode), so adding
it there won't work. Realistically, we probably *will* want to put any
optimised versions in a separate directory, so creating it now is harmless.

rdar://problem/17613576

llvm-svn: 212696

Differential Revision: http://reviews.llvm.org/D4418

llvm-svn: 212693

Differential Revision: http://reviews.llvm.org/D4420

llvm-svn: 212691

Differential Revision: http://reviews.llvm.org/D4229

llvm-svn: 212690

llvm-svn: 212665

Patch by Kuba Brecka!

llvm-svn: 212664

Otherwise, it can be accidentally redefined when we build specific sanitizer
runtime. This definition should be provided only once - when we build
sanitizer_common library.

llvm-svn: 212663

llvm-svn: 212642

don't reset s->addr as well

llvm-svn: 212565

They cause "check-tsan" command to hang. Details in r212532 review thread.

llvm-svn: 212562

JVM actually moves memory between overlapping ranges.

llvm-svn: 212560

llvm-svn: 212534

The tsan's deadlock detector has been used in Chromium for a while;
it found a few real bugs and reported no false positives.
So, it's time to give it a bit more exposure.

llvm-svn: 212533