[ASan] don't call strerr from functions that map memory, since this results in malloc().


git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@176800 91177308-0d34-0410-b5e6-96231b3b80d8
[ASan] Try to use a small (512 bytes) stack-local buffer in Report() for short messages, fall back to MmapOrDie() in the case of a failure.
This shall eliminate most of the cryptic "ERROR: failed to mmap" messages caused by recursively calling MmapOrDie() from MmapOrDie().


git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@176802 91177308-0d34-0410-b5e6-96231b3b80d8
[ASan] Reduce the local buffer size in Report() not to fail the check enforced when building TSan runtime.


git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@176804 91177308-0d34-0410-b5e6-96231b3b80d8
[Sanitizer] Implement BlockingMutex::CheckLocked()

git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@176805 91177308-0d34-0410-b5e6-96231b3b80d8
[msan] intercept dlopen and clear shadow for it

Summary:
The loader does not call mmap() through the PLT because it has to
bootstrap the process before libc is present.  Hooking dlopen() isn't
enough either because the loader runs module initializers before
returning, and they could run arbitrary msan instrumented code.

If msandr is present, then we can intercept the mmaps from dlopen at the
syscall layer and clear the shadow there.  If msandr is missing, we
clear the shadow after dlopen() and hope any initializers are trivial.

Reviewers: eugenis

CC: kcc, llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D509

git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@176818 91177308-0d34-0410-b5e6-96231b3b80d8
[sanitizer] simplify the allocator's SizeClassMap: do not require an extra template parameter, instead compute it in flight. No functionality change

git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@176853 91177308-0d34-0410-b5e6-96231b3b80d8
[msan] Use sptr instead of ptrdiff_t.


git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@176854 91177308-0d34-0410-b5e6-96231b3b80d8
[sanitizer] use fewer size classes in the allocator to reduce the memory footprint. There is no all-size-fits-all constant here, but this change is positive or neutral on several large apps I've tested

git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@176855 91177308-0d34-0410-b5e6-96231b3b80d8
[asan] use 4Tb of address space for the asan allocator instead of 1Tb. This increases the memory available for a single size class from 16Gb to 64Gb. The total VM footprint becomes 20Tb

git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@176857 91177308-0d34-0410-b5e6-96231b3b80d8