For ARM cores that are ARMv6T2+ but not ARMv7ve or ARMv7-r and not an updated
ARMv7-a that has the idiv extension (chips with clz but not idiv), an incorrect
jump would be calculated due to the preference to thumb instructions over ARM.
Rather than computing the target at runtime, use a jumptable instead. This
trades a bit of storage for performance. The overhead is 32-bytes for each of
the three routines, but avoid the calculation of the offset.
Because clz was introduced in ARMv6T2 and idiv in certain versions of ARMv7,
the non-clz, non-idiv case implies a target which does not support Thumb-2, and
thus we cannot use Thumb on those targets (as it is unlikely that the assembly
will assemble).
Take the opportunity to refactor the IT block macros into assembly.h rather than
redefining them in the TUs where they are used.
Existing tests cover the full change already, so no new tests are added.
This effectively reverts SVN r213309.
llvm-svn: 213467
The udivmodsi4/modsi3/umodsi3 code computes jump targets based on ARM encodings
(if CLZ is present and IDIV is not present).
Reverts parts of r211032 and r211035.
llvm-svn: 213309
Format of __libc_malloc_dispatch has changed in Android L.
While we are moving towards a solution that does not depend on bionic
internals, here is something to support both K* and L releases.
llvm-svn: 213263
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
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
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
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
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
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
The bug happens in the following case:
Mutex is located at heap block beginning,
when we call MutexDestroy, s->next is set to 0,
so free can't find the MBlock related to the block.
llvm-svn: 212531
Introduce new public header <sanitizer/allocator_interface.h> and a set
of functions __sanitizer_get_ownership(), __sanitizer_malloc_hook() etc.
that will eventually replace their tool-specific equivalents
(__asan_get_ownership(), __msan_get_ownership() etc.). Tool-specific
functions are now deprecated and implemented as stubs redirecting
to __sanitizer_ versions (which are implemented differently in each tool).
Replace all uses of __xsan_ versions with __sanitizer_ versions in unit
and lit tests.
llvm-svn: 212469
Joerg Sonnenberger