Sanitizers are intentionally not including system headers and often declare slightly different function prototypes, which is incompatible with -fmodules and -fcxx-modules. Let’s simply exclude compiler-rt from using -fmodules.
Differential Revision: https://reviews.llvm.org/D25230
llvm-svn: 283658
Used uptr for __sanitizer_kernel_sigset_t.sig to avoid byte order issues on big endian systems
Reviewd by bruening.
Differential: D24332
llvm-svn: 283438
The VM layout is not stable between iOS version releases, so switch to dynamic shadow offset.
Differential Revision: https://reviews.llvm.org/D25218
llvm-svn: 283375
Reapply 282061.
One of the tests relying on sem_t's layout gets the wrong value for versions of
glibc newer than 2.21 on platforms that don't have 64-bit atomics (e.g. ARM).
This commit fixes the test to work with:
* versions of glibc >= 2.21 on platforms with 64-bit atomics: unchanged
* versions of glibc >= 2.21 on platforms without 64-bit atomics: the semaphore
value is shifted by SEM_VALUE_SHIFT (which is set to 1 in glibc's internal
headers)
* versions of glibc < 2.21: unchanged
The logic is complicated a bit by the fact that the sanitizers always pick the
oldest version of the symbol available in glibc, which creates discrepancies
between old platforms which contain several versions od the sem_init symbol, and
newer platforms which contain only one.
See the glibc 2.23 sources:
* sysdeps/nptl/internaltypes.h (struct new_sem for glibc >= 2.21 and
struct old_sem for glibc < 2.21)
* nptl/sem_getvalue.c
This was uncovered on one of the new buildbots that we are trying to move to
production.
Differential Revision: https://reviews.llvm.org/D24766
llvm-svn: 283299
The VM layout is not stable between iOS version releases, so switch to dynamic shadow offset.
Differential Revision: https://reviews.llvm.org/D25218
llvm-svn: 283240
Summary:
Handles early allocation from dlsym by allocating memory from a local
static buffer.
Reviewers: bruening
Subscribers: kubabrecka
Differential Revision: https://reviews.llvm.org/D25193
llvm-svn: 283139
Summary:
s/CHECK_LT/CHECK_LE/ in the secondary allocator, as under certain circumstances
Ptr + Size can be equal to MapEnd. This edge case was not found by the current
tests, so those were extended to be able to catch that.
Reviewers: kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25101
llvm-svn: 282913
Summary:
The check-asan-dynamic tests were broken on win10 because the interception
library was not able to hook on some functions.
credits: thanks sebastian marchand to help debugging this on win10.
Reviewers: rnk
Subscribers: chrisha, llvm-commits, dberris
Differential Revision: https://reviews.llvm.org/D25120
llvm-svn: 282904
Summary:
This patch is adding support for dynamic shadow allocation.
This is a merge and re-commit of the following patches.
```
[compiler-rt] Fix Asan build on Android
https://reviews.llvm.org/D24768
[compiler-rt] Add support for the dynamic shadow allocation
https://reviews.llvm.org/D23363
```
This patch needed to re-land at the same time:
```
[asan] Support dynamic shadow address instrumentation
https://reviews.llvm.org/D23354
```
Reviewers: rnk, zaks.anna
Subscribers: tberghammer, danalbert, kubabrecka, dberris, chrisha, llvm-commits
Differential Revision: https://reviews.llvm.org/D25104
llvm-svn: 282882
Summary:
This test is broken on wndows 64-bit.
The interception library is not able to hook on the memchr functions.
Snippet of the function that is not hookable:
```
--- No source file -------------------------------------------------------------
000007FEFA1A18CD CC int 3
000007FEFA1A18CE CC int 3
000007FEFA1A18CF CC int 3
--- f:\dd\vctools\crt\vcruntime\src\string\amd64_arm_arm64\memchr.c ------------
while ( cnt && (*(unsigned char *)buf != (unsigned char)chr) ) {
000007FEFA1A18D0 4D 85 C0 test r8,r8
000007FEFA1A18D3 74 0D je memchr+12h (07FEFA1A18E2h)
000007FEFA1A18D5 38 11 cmp byte ptr [rcx],dl
000007FEFA1A18D7 74 09 je memchr+12h (07FEFA1A18E2h)
buf = (unsigned char *)buf + 1;
000007FEFA1A18D9 48 FF C1 inc rcx
cnt--;
000007FEFA1A18DC 49 83 E8 01 sub r8,1
000007FEFA1A18E0 75 F3 jne memchr+5h (07FEFA1A18D5h)
}
```
Reviewers: rnk
Subscribers: kubabrecka, dberris, llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D25037
llvm-svn: 282860
Summary:
On windows, the memcpy and memmove function can be the same.
This is correcly detected when hooking, but it's not possible
to report the right function name when doing symbolisation.
The same fix was applied for the static asan unittest.
We forgot to apply the fix for the dynamic asan tests.
```
lvm\projects\compiler-rt\test\asan/TestCases/Windows/.svn/text-base/intercept_memcpy.cc.svn-base:// CHECK-NEXT: __asan_{{.*}}mem{{.*}}
```
This patch is fixing this test (win64):
```
ddressSanitizer-x86_64-windows-dynamic :: TestCases/Windows/dll_intercept_memcpy_indirect.cc
```
Reviewers: rnk, vitalybuka
Subscribers: llvm-commits, kubabrecka, chrisha, dberris
Differential Revision: https://reviews.llvm.org/D25038
llvm-svn: 282859
Summary:
The MSVC compiler is generating multiple instance of the exception handler
when compiling on win64 with /MD.
see: https://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx
Two tests were failing when running:
```
ninja check-asan-dynamic.
```
The tests were failing because only the first occurence of the function was patched.
The function `__C_specific_handler` is defined in `ntdll` and `vcruntime140`.
After this patch, there is still two remaining tests failing.
```
********************
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
Testing Time: 87.81s
********************
Failing Tests (2):
AddressSanitizer-x86_64-windows-dynamic :: TestCases/Windows/dll_intercept_memchr.cc
AddressSanitizer-x86_64-windows-dynamic :: TestCases/Windows/dll_intercept_memcpy_indirect.cc
Expected Passes : 342
Passes With Retry : 2
Expected Failures : 16
Unsupported Tests : 152
Unexpected Failures: 2
```
Reviewers: rnk, vitalybuka
Subscribers: vitalybuka, llvm-commits, chrisha, dberris
Differential Revision: https://reviews.llvm.org/D24983
llvm-svn: 282614
This patch extends __sanitizer_finish_switch_fiber method to optionally return previous stack base and size.
This solves the problem of coroutines/fibers library not knowing the original stack context from which the library is used. It's incorrect to assume that such context is always the default stack of current thread (e.g. one such library may be used from a fiber/coroutine created by another library). Bulding a separate stack tracking mechanism would not only duplicate AsanThread, but also require each coroutines/fibers library to integrate with it.
Author: Andrii Grynenko (andriigrynenko)
Reviewed in: https://reviews.llvm.org/D24628
llvm-svn: 282582
This is a follow up to r282152.
A more extensive testing on real apps revealed a subtle bug in r282152.
The revision made shadow mapping non-linear even within a single
user region. But there are lots of code in runtime that processes
memory ranges and assumes that mapping is linear. For example,
region memory access handling simply increments shadow address
to advance to the next shadow cell group. Similarly, DontNeedShadowFor,
java memory mover, search of heap memory block header, etc
make similar assumptions.
To trigger the bug user range would need to cross 0x008000000000 boundary.
This was observed for a module data section.
Make shadow mapping linear within a single user range again.
Add a startup CHECK for linearity.
llvm-svn: 282405
Don't xor user address with kAppMemXor in meta mapping.
The only purpose of kAppMemXor is to raise shadow for ~0 user addresses,
so that they don't map to ~0 (which would cause overlap between
user memory and shadow).
For meta mapping we explicitly add kMetaShadowBeg offset,
so we don't need to additionally raise meta shadow.
llvm-svn: 282403
It's wrong to pass to MsanReallocate a pointer that MSan allocator doesn't own.
Use nullptr instead of ptr to prevent possible (still unlikely) failure.
llvm-svn: 282390
This reverts commit r282294. It breaks a Linux bot:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/12180
It looks like the test checks that __llvm_profile_set_filename() alters the raw
profile filename in both the dylib and the main program. Now that
lprofCurFilename is hidden, this can't work, and we get two profiles (one for
the call to "main" and one for "func").
Back this change out so that we don't affect external users.
llvm-svn: 282304
Profile-aarch64 :: Linux/comdat_rename.test
Profile-aarch64 :: Linux/extern_template.test
Profile-aarch64 :: Linux/instrprof-comdat.test
Profile-aarch64 :: Linux/instrprof-cs.c
The issue is that the created (aarch64) binaries were attempting to run natively
instead of running through %run, which guarantees running in the proper
environment if the compilation was configured correctly.
llvm-svn: 282264
Summary:
The 'asan_preload_test-1.cc' is not working with the i686 architecture.
To repro the error, run on a linux 64-bit:
```
ninja check-asan-dynamic
```
The following error occurs:
```
--
Exit Code: 1
Command Output (stderr):
--
/home/llvm/llvm/projects/compiler-rt/test/asan/TestCases/Linux/asan_preload_test-1.cc:18:12: error: expected string not found in input
// CHECK: AddressSanitizer: heap-buffer-overflow
^
<stdin>:1:1: note: scanning from here
ERROR: ld.so: object 'libclang_rt.asan-i686.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
^
<stdin>:2:10: note: possible intended match here
==25982==AddressSanitizer CHECK failed: /home/llvm/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:736 "((__interception::real_memcpy)) != (0)" (0x0, 0x0)
```
The unittest is running (where %shared_libasan is replaced by libclang_rt.asan-i686.so):
```
// RUN: env LD_PRELOAD=%shared_libasan not %run %t 2>&1 | FileCheck %s
```
But the executable also has a dependancy on libclang_rt.asan-i386.so (added by the clang driver):
```
linux-gate.so.1 => (0xf77cc000)
libclang_rt.asan-i386.so => not found
libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xf76ba000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7673000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7656000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf74a7000)
```
By looking to the clang driver (tools.cpp) we can see that every x86 architecture are mapped to 'i386'.
```
StringRef MyArch;
switch (getToolChain().getArch()) {
case llvm::Triple::arm:
MyArch = "arm";
break;
case llvm::Triple::x86:
MyArch = "i386";
break;
case llvm::Triple::x86_64:
MyArch = "amd64";
break;
default:
llvm_unreachable("Unsupported architecture");
}
```
This patch is implementing the same mapping but in the compiler-rt unittest.
Reviewers: rnk, vitalybuka
Subscribers: aemerson, kubabrecka, dberris, llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D24838
llvm-svn: 282263
On Darwin, -lm, -pthread and others are implied. -pthread currently produces a warning (compiler option unused).
Differential Revision: https://reviews.llvm.org/D24698
llvm-svn: 282260
Summary:
Window compiler is stricter for attributes location. This patch fixes a compilation error.
```
D:\src\llvm\llvm\projects\compiler-rt\lib\lsan\lsan_thread.cc(39): error C2144: syntax error: 'int' should be preceded by ';'
```
Reviewers: rnk, majnemer
Subscribers: majnemer, llvm-commits, chrisha, dberris
Differential Revision: https://reviews.llvm.org/D24810
llvm-svn: 282254
Kuba Brecka