Looks like we are missing these flags only in tsan and sanitizer-common.
This results in linker warnings in some settings as it can cause the Unit
tests to be built with a different SDK version than that was used to build
the runtime. For example, we are not setting the minimal deployment target
on the tests but are setting the minimal deployment target for the sanitizer
library, which leads to the following warning on some bots: ld: warning:
object file (sanitizer_posix_test.cc.i386.o) was built for newer OSX version
(10.12) than being linked (10.11).
Differential Revision: https://reviews.llvm.org/D25860https://reviews.llvm.org/D25352
llvm-svn: 285255
Summary:
In order to support 32-bit platforms, we have to make some adjustments in
multiple locations, one of them being the Scudo chunk header. For it to fit on
64 bits (as a reminder, on x64 it's 128 bits), I had to crunch the space taken
by some of the fields. In order to keep the offset field small, the secondary
allocator was changed to accomodate aligned allocations for larger alignments,
hence making the offset constant for chunks serviced by it.
The resulting header candidate has been added, and further modifications to
allow 32-bit support will follow.
Another notable change is the addition of MaybeStartBackgroudThread() to allow
release of the memory to the OS.
Reviewers: kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25688
llvm-svn: 285209
clear_cache is using R7 for the SVC call and that's the frame pointer in
GCC, which is only disabled on -O2/3, so Release builds finish, Debug don't.
Fixes PR30797.
llvm-svn: 285204
Summary: Newer versions of clang complain that __asan_schedule_unregister_globals is unused. Moving it outside the anonymous namespace gets rid of that warning.
Reviewers: rnk, timurrrr
Subscribers: kubabrecka, dberris
Differential Revision: https://reviews.llvm.org/D25921
llvm-svn: 285010
This makes __llvm_profile_set_filename() work across dylib boundaries on
Darwin.
This functionality was originally meant to work on all platforms, but
was moved to a Linux-only directory with r272404. The root cause of the
test failure on Darwin was that lprofCurFilename was not marked weak.
Each dylib maintained its own copy of the variable due to the two-level
namespace.
Tested with check-profile (on Darwin). I don't expect this to regress
other platforms.
Differential Revision: https://reviews.llvm.org/D25707
llvm-svn: 284440
Summary:
This change depends on D23986 which adds tail call-specific sleds. For
now we treat them first as normal exits, and in the future leave room
for implementing this as a different kind of log entry.
The reason for deferring the change is so that we can keep the naive
logging implementation more accurate without additional complexity for
reading the log. The accuracy is gained in effectively interpreting call
stacks like:
A()
B()
C()
Which when tail-call merged will end up not having any exit entries for
A() nor B(), but effectively in turn can be reasoned about as:
A()
B()
C()
Although we lose the fact that A() had called B() then had called C()
with the naive approach, a later iteration that adds the explicit tail
call entries would be a change in the log format and thus necessitate a
version change for the header. We can do this later to have a chance at
releasing some tools (in D21987) that are able to handle the naive log
format, then support higher version numbers of the log format too.
Reviewers: echristo, kcc, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, dberris
Differential Revision: https://reviews.llvm.org/D23988
llvm-svn: 284178
Summary:
LeakSanitizer does not work with ptrace but currently it
will print warnings (only under verbosity=1) and then proceed
to print tons of false reports.
This patch makes lsan fail hard under ptrace with a verbose message.
https://github.com/google/sanitizers/issues/728
Reviewers: eugenis, vitalybuka, aizatsky
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D25538
llvm-svn: 284171
Some of our existing tests hang on the new Windows bot with this stack:
770, clang_rt.asan_dynamic-i386.dll!__asan::AsanTSDGet+0x3e
771, clang_rt.asan_dynamic-i386.dll!__asan::GetCurrentThread+0x9
772, clang_rt.asan_dynamic-i386.dll!__asan_handle_no_return+0xe
773, clang_rt.asan_dynamic-i386.dll!__asan_wrap__except_handler4_common+0x12
774, ntdll.dll!wcstombs+0xb0 (No unwind info)
775, ntdll.dll!ZwWow64CallFunction64+0x2001 (No unwind info)
776, ntdll.dll!ZwWow64CallFunction64+0x1fd3 (No unwind info)
777, ntdll.dll!KiUserExceptionDispatcher+0xf (No unwind info)
778, clang_rt.asan_dynamic-i386.dll!destroy_fls+0x13
779, ntdll.dll!RtlLockHeap+0xea (No unwind info)
780, ntdll.dll!LdrShutdownProcess+0x7f (No unwind info)
781, ntdll.dll!RtlExitUserProcess+0x81 (No unwind info)
782, kernel32.dll!ExitProcess+0x13 (No unwind info)
783, clang_rt.asan_dynamic-i386.dll!__sanitizer::internal__exit+0xc
784, clang_rt.asan_dynamic-i386.dll!__sanitizer::Die+0x3d
785, clang_rt.asan_dynamic-i386.dll!__asan::AsanInitInternal+0x50b
786, clang_rt.asan_dynamic-i386.dll!__asan::Allocator::Allocate+0x1c
787, clang_rt.asan_dynamic-i386.dll!__asan::Allocator::Calloc+0x43
We hang because AsanDie tries to defend against multi-threaded death by
infinite looping if someone is already exiting. We might want to
reconsider that, but one easy way to avoid getting here is not to let
our noreturn interceptors call back into fragile parts of ASan.
llvm-svn: 284067
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
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:
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
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
In ShadowToMem we call MemToShadow potentially for incorrect addresses.
So DCHECK(IsAppMem(p)) can fire in debug mode.
Fix this by swapping range and MemToShadow checks.
llvm-svn: 282157
4.1+ Linux kernels map pie binaries at 0x55:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d1fd836dcf00d2028c700c7e44d2c23404062c90
Currently tsan does not support app memory at 0x55 (https://github.com/google/sanitizers/issues/503).
Older kernels also map pie binaries at 0x55 when ASLR is disables (most notably under gdb).
This change extends tsan mapping for linux/x86_64 to cover 0x554-0x568 app range and fixes both 4.1+ kernels and gdb.
This required to slightly shrink low and high app ranges and move heap. The mapping become even more non-linear, since now we xor lower bits. Now even a continuous app range maps to split, intermixed shadow ranges. This breaks ShadowToMemImpl as it assumes linear mapping at least within a continuous app range (however it turned out to be already broken at least on arm64/42-bit vma as uncovered by r281970). So also change ShadowToMemImpl to hopefully a more robust implementation that does not assume a linear mapping.
llvm-svn: 282152
For mips assember '#' is the start of comment. We get assembler error messages if # is used in the struct names. Therefore using '$' which works for all architectures.
Differential: D24335
Reviewed by: zhaoqin
llvm-svn: 282142
Summary:
Finish work on PR30351 (last one, after D24551, D24552, and D24554 land)
Also replace the old ReportData structure/variable with the current_error_ static
member of the ScopedInErrorReport class.
This has the following side-effects:
- Move ASAN_ON_ERROR(); call to the start of the destructor, instead
of in StartReporting().
- We only generate the error structure after the
ScopedInErrorReport constructor finishes, so we can't call
ASAN_ON_ERROR() during the constructor. I think this makes more
sense, since we end up never running two of the ASAN_ON_ERROR()
callback. This also works the same way as error reporting, since
we end up having a lock around it. Otherwise we could end up
with the ASAN_ON_ERROR() call for error 1, then the
ASAN_ON_ERROR() call for error 2, and then lock the mutex for
reporting error 1.
- The __asan_get_report_* functions will be able to, in the future,
provide information about other errors that aren't a "generic
error". But we might want to rethink that API, since it's too
restricted. Ideally we teach lldb about the current_error_ member of
ScopedInErrorReport.
Reviewers: vitalybuka, kcc, eugenis
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D24555
llvm-svn: 282107
Summary:
The dynamic shadow code is not detected correctly on Android.
The android shadow seems to start at address zero.
The bug is introduced here:
https://reviews.llvm.org/D23363
Started here: https://build.chromium.org/p/chromium.fyi/builders/ClangToTAndroidASan/builds/4029
Likely due to an asan runtime change, filed https://llvm.org/bugs/show_bug.cgi?id=30462
From asan_mapping.h:
```
#if SANITIZER_WORDSIZE == 32
# if SANITIZER_ANDROID
# define SHADOW_OFFSET (0) <<---- HERE
# elif defined(__mips__)
```
Shadow address on android is 0.
From asan_rtl.c:
```
if (shadow_start == 0) {
[...]
shadow_start = FindAvailableMemoryRange(space_size, alignment, granularity);
}
```
We assumed that 0 is dynamic address.
On windows, the address was determined with:
```
# elif SANITIZER_WINDOWS64
# define SHADOW_OFFSET __asan_shadow_memory_dynamic_address
# else
```
and __asan_shadow_memory_dynamic_address is initially zero.
Reviewers: rnk, eugenis, vitalybuka
Subscribers: kcc, tberghammer, danalbert, kubabrecka, dberris, llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D24768
llvm-svn: 282085
Summary:
GetActuallyAllocatedSize() was not accounting for the last page of the mapping
being a guard page, and was returning the wrong number of actually allocated
bytes, which in turn would mess up with the realloc logic. Current tests didn't
find this as the size exercised was only serviced by the Primary.
Correct the issue by subtracting PageSize, and update the realloc test to
exercise paths in both the Primary and the Secondary.
Reviewers: kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24787
llvm-svn: 282030
Summary:
The Sanitizer Secondary Allocator was not entirely ideal was Scudo for several
reasons: decent amount of unneeded code, redundant checks already performed by
the front end, unneeded data structures, difficulty to properly protect the
secondary chunks header.
Given that the second allocator is pretty straight forward, Scudo will use its
own, trimming all the unneeded code off of the Sanitizer one. A significant
difference in terms of security is that now each secondary chunk is preceded
and followed by a guard page, thus mitigating overflows into and from the
chunk.
A test was added as well to illustrate the overflow & underflow situations
into the guard pages.
Reviewers: kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24737
llvm-svn: 281938
Summary:
This patch is adding the needed code to compiler-rt to support
dynamic shadow.
This is to support this patch:
https://reviews.llvm.org/D23354
It's adding support for using a shadow placed at a dynamic address determined
at runtime.
The dynamic shadow is required to work on windows 64-bits.
Reviewers: rnk, kcc, vitalybuka
Subscribers: kubabrecka, dberris, llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D23363
llvm-svn: 281909
Summary:
This value is already defaulted to true in asan_internal.h.
Allow the value to be overriden in cases where exceptions are unavailable.
Reviewers: kcc, samsonov, compnerd
Subscribers: kubabrecka, dberris, beanz, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D24633
llvm-svn: 281746
The definitions in sanitizer_common may conflict with definitions from system headers because:
The runtime includes the system headers after the project headers (as per LLVM coding guidelines).
lib/sanitizer_common/sanitizer_internal_defs.h pollutes the namespace of everything defined after it, which is all/most of the sanitizer .h and .cc files and the included system headers with: using namespace __sanitizer; // NOLINT
This patch solves the problem by introducing the namespace only within the sanitizer namespaces as proposed by Dmitry.
Differential Revision: https://reviews.llvm.org/D21947
llvm-svn: 281657
These got out of sync and the tests were failing for me locally. We
assume a 47 bit address space in ASan, so we should do the same in the
tests.
llvm-svn: 281622
Don't list __sanitizer_print_memory profile as an INTERFACE_FUNCTION. It
is not exported by ASan; it is exported by user code.
Move the weak definition from asan_win.cc to sanitizer_win.cc to fix the
ubsan tests.
llvm-svn: 281619
Summary:
ASAN on Windows 64-bits should use a dynamic address instead of a fixed one.
The asan-allocator code to support dynamic address is already landed.
This patch is turning on the feature.
Reviewers: rnk
Subscribers: kubabrecka, dberris, llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D24575
llvm-svn: 281522
When running with start_deactivated=1 in ASAN_OPTIONS, heap redzones
are not poisoned until the first instrumented module is loaded. This
can cause false negatives even on memory allocated after activation,
because redzones are normally poisoned only once when a new allocator
region is mapped.
This change attempts to fix it by iterating over all existing
allocator chunks and poisoning their redzones.
llvm-svn: 281364
Summary:
Added a macro to enumerate the (error name, error member name) pairs. This way,
when adding an error, we only need to add the pair to one place (plus add its
implementation, or course).
Reviewers: kcc, samsonov
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23875
llvm-svn: 281237
Summary: As mentioned in D24394, I'm moving tid to ErrorBase, since basically all errors need it.
Also mentioned in the same review are other cleanups like adding const
to BufferedStackTrace and make sure constructor orders are consistent.
Reviewers: vitalybuka, kcc, eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D24455
llvm-svn: 281236
Summary:
This is important information when we want to describe errors, and should be
part of these descriptions. Otherwise, we need to know the access size when
printing/emitting the description.
Reviewers: kcc, eugenis, vitalybuka
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D24387
llvm-svn: 281093
Summary:
This is useful for inclusion in the Error* structures, to describe an
arbitrary address.
Remove the old struct since it's used only once. This removes one level of
indirection, and moves all *AddressDescription to be one of the recently
introduced structures.
This merges differential revisions: D24131 and D24132
Reviewers: kcc, eugenis, vitalybuka
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D24131
llvm-svn: 281090
r280885 added a testcase for handle_abort, which is broken on macOS, let’s add this support into sanitizer_mac.cc.
Differential Revision: https://reviews.llvm.org/D24344
llvm-svn: 280945
This patch adds a wrapper for call_once, which uses an already-compiled helper __call_once with an atomic release which is invisible to TSan. To avoid false positives, the interceptor performs an explicit atomic release in the callback wrapper.
Differential Revision: https://reviews.llvm.org/D24188
llvm-svn: 280920
Reset the SIGABRT signal handler before calling abort().
Also, change the error message when catching SIGABRT to say "ABRT"
instead of "SEGV".
llvm-svn: 280885
On Linux ARM, the syscall will take 3 arguments (start, end, flags). Ensure
that we do not pass garbage to the flags, which can cause the cacheflush call to
fail, and therefore cause an abort at runtime.
llvm-svn: 280877
Android-specific code in GetCurrentThread() does not handle the situation when there is no
ThreadContext for the current thread. This happens if the current thread is requested before the
main thread is added to the registry. 64-bit allocator does that to record map/unmap stats during
initialization.
llvm-svn: 280876
Normally, syslog() uses argv[0] for the log tag; bionic, however,
would crash in syslog() before libc constructor unless the log
tag is explicitly set with openlog().
llvm-svn: 280875
Summary:
A few small changes required to permit building the sanitizers
with Clang instead of only with MSVC.
Reviewers: compnerd, beanz, rnk
Subscribers: beanz, timurrrr, kubabrecka, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D24092
llvm-svn: 280863
Since r279664 this test causes frequent failures of test runs for ppc64le and
occasional failures for ppc64be which makes buildbot results unreliable. If
the underlying problem is fixed it can be re-enabled.
llvm-svn: 280823
With this patch 10 out of 13 tests are passing.
Following is the list of failing tests:
struct-simple.cpp
workingset-signal-posix.cpp
mmap-shadow-conflict.c
Reviewed by bruening
Differential: D23799
llvm-svn: 280795
When optimizing, GCC optimizes away aggressively unused static globals.
The __asan_before_dynamic_init/__asan_after_dynamic_init calls are placed
in static constructor earlier while the registration of the globals is done
later in the compilation process. If all the globals with
dynamic initialization are optimized away from some particular TU in between
those two, libasan can fail on an assertion that dynamic_init_globals is
empty.
While I'm going to commit a GCC change which will remove the
__asan_before_dynamic_init/__asan_after_dynamic_init in many cases when this
happens (basically if the optimizers can prove there are no memory
references in between the two calls), there are still testcases where such
pair of calls is left, e.g. for
struct S { S () { asm volatile ("" : : : "memory"); } };
static S c;
int
main ()
{
return 0;
}
with -O2 -fsanitize=address and ASAN_OPTIONS=check_initialization_order=true
this still fails the assertion. Trying to avoid this problem on the
compiler side would decrease code quality I'm afraid, whether it is making
sure for -fsanitize=address we keep around at least one dynamically
initialized global if the
__asan_before_dynamic_init/__asan_after_dynamic_init pair has been emitted,
or adding some artificial global which would be used as the condition for
those calls etc.
So, can the assertion be instead just removed, this really shouldn't slow
down the calls measurably (for __asan_before_dynamic_init it is even
cheaper) and the assertion doesn't check something worthwhile anyway (it is
sufficient if there is a single dynamically initialized global in any other
TU to make it happy).
Details in http://gcc.gnu.org/PR77396
Author: Jakub Jelinek
llvm-svn: 280657
The atomic builtin source is problematic when cross-compiling builtins because it requires a variable and sometimes large set of system headers. This option allows users to optionally prevent it from being built.
llvm-svn: 280416
Summary:
@kcc: I know you've accepted the other revision, but since this is a
non-trivial change, I'm updating it to show why D24029 would help.
This commit sets up the infrastructure to use reified error
descriptions, and moves ReportStackOverflow to the new system.
After we convert all the errors, we'll be able to simplify ScopedInErrorReport
and remove the older debugging mechanism which had some errors partly reified
in some way. We'll be able to maintain the external API.
ScopedInErrorReport will be able to track one of the reified errors at a time.
The purpose of this is so we have its destructor actually print the error and
possibly interface with the debugger (will depend on the platform, of course).
Reviewers: kcc, samsonov, timurrrr
Subscribers: kcc, llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D24030
llvm-svn: 280111
Summary:
This is needed so we can use it for D23672 on VS2013, since this VS
version doesn't support unrestricted unions, and doesn't allow us to
uses an object without a trivial default constructor inside a union.
Reviewers: kcc, samsonov
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D24029
llvm-svn: 280110
Summary:
We are going to use store instructions to poison some allocas.
Runtime flag will require branching in instrumented code on every lifetime
intrinsic. We'd like to avoid that.
Reviewers: eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23967
llvm-svn: 279981
Summary:
This commit sets up the infrastructure to use reified error
descriptions, and moves ReportStackOverflow to the new system.
After we convert all the errors, we'll be able to simplify ScopedInErrorReport
and remove the older debugging mechanism which had some errors partly reified
in some way. We'll be able to maintain the external API.
ScopedInErrorReport will be able to track one of the reified errors at a time.
The purpose of this is so we have its destructor actually print the error and
possibly interface with the debugger (will depend on the platform, of course).
Reviewers: kcc, samsonov, timurrrr
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D23672
llvm-svn: 279931
This patch builds on LLVM r279776.
In this patch I've done some cleanup and abstracted three common steps runtime components have in their CMakeLists files, and added a fourth.
The three steps I abstract are:
(1) Add a top-level target (i.e asan, msan, ...)
(2) Set the target properties for sorting files in IDE generators
(3) Make the compiler-rt target depend on the top-level target
The new step is to check if a command named "runtime_register_component" is defined, and to call it with the component name.
The runtime_register_component command is defined in llvm/runtimes/CMakeLists.txt, and presently just adds the component to a list of sub-components, which later gets used to generate target mappings.
With this patch a new workflow for runtimes builds is supported. The new workflow when building runtimes from the LLVM runtimes directory is:
> cmake [...]
> ninja runtimes-configure
> ninja asan
The "runtimes-configure" target builds all the dependencies for configuring the runtimes projects, and runs CMake on the runtimes projects. Running the runtimes CMake generates a list of targets to bind into the top-level CMake so subsequent build invocations will have access to some of Compiler-RT's targets through the top-level build.
Note: This patch does exclude some top-level targets from compiler-rt libraries because they either don't install files (sanitizer_common), or don't have a cooresponding `check` target (stats).
llvm-svn: 279863
Summary:
This commit sets up the infrastructure to use reified error
descriptions, and moves ReportStackOverflow to the new system.
After we convert all the errors, we'll be able to simplify ScopedInErrorReport
and remove the older debugging mechanism which had some errors partly reified
in some way. We'll be able to maintain the external API.
ScopedInErrorReport will be able to track one of the reified errors at a time.
The purpose of this is so we have its destructor actually print the error and
possibly interface with the debugger (will depend on the platform, of course).
Reviewers: kcc, samsonov, timurrrr
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D23672
llvm-svn: 279862
Summary: This will allow for the sanitizers to be used when c++ abi is unavailable.
Reviewers: samsonov, beanz, pcc, rnk
Subscribers: llvm-commits, kubabrecka, compnerd, dberris
Differential Revision: https://reviews.llvm.org/D23376
llvm-svn: 279816
Depends on D21612 which implements the building blocks for the compiler-rt
implementation of the XRay runtime. We use a naive in-memory log of fixed-size
entries that get written out to a log file when the buffers are full, and when
the thread exits.
This implementation lays some foundations on to allowing for more complex XRay
records to be written to the log in subsequent changes. It also defines the format
that the function call accounting tool in D21987 will start building upon.
Once D21987 lands, we should be able to start defining more tests using that tool
once the function call accounting tool becomes part of the llvm distribution.
Reviewers: echristo, kcc, rnk, eugenis, majnemer, rSerge
Subscribers: sdardis, rSerge, dberris, tberghammer, danalbert, srhines, majnemer, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D21982
llvm-svn: 279805
This patch adds 48-bits VMA support for msan on aarch64. As current
mappings for aarch64, 48-bit VMA also supports PIE executable.
Tested on 39 and 48-bit VMA kernels on aarch64.
llvm-svn: 279753
This patch adds 48-bits VMA support for msan on aarch64. As current
mappings for aarch64, 48-bit VMA also supports PIE executable. The
48-bits segments only cover the usual PIE/default segments plus some
more segments (262144GB total, 0.39% total VMA). Memory avaliability
can be increase by adding multiple application segments like 39 and
42 mapping (some mappings were added on this patch as well).
Tested on 39 and 48-bit VMA kernels on aarch64.
llvm-svn: 279752
Summary:
Since we can now build the builtins without a full toolchain these files should no longer be needed.
This is the last vestige of autoconf!
Reviewers: compnerd, iains, jroelofs
Subscribers: dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D23777
llvm-svn: 279539
Summary:
This does not actually fixes the test.
AddressSanitizer::OOB_char behavior is inconsistent but it somehow usually
works. On arm it runs more iterations than expected. And adding a new test with AddressSanitizerInterface prefix, even empty, somehow breaks OOB_char test.
So I will rename my test to make the bot green and will continue to investigate the test.
Reviewers: krasin
Subscribers: aemerson, rengolin, kubabrecka, llvm-commits, samparker
Differential Revision: https://reviews.llvm.org/D23790
llvm-svn: 279501
Summary: This fixes the omission of -fPIC when building the builtins.
Reviewers: compnerd, beanz
Subscribers: dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D23729
llvm-svn: 279469
Summary:
On apple targets, when SANITIZER_CAN_USE_CXXABI is false,
the ubsan cxxabi sources aren't built, since they're unused.
Do this on non-apple targets as well.
This fixes errors when linking sanitizers if c++ abi is
unavailable.
Reviewers: pcc, kubabrecka, beanz
Subscribers: rnk, llvm-commits, kubabrecka, compnerd, dberris
Differential Revision: https://reviews.llvm.org/D23638
llvm-svn: 279467
Introduce a new CMake option `COMPILER_RT_SANITIZERS_TO_BUILD` which takes
either a special token `all` (default) which will preserve the current behaviour
or a CMake list of sanitizers to build. It will still perform the normal checks
if the sanitizer is requested. It only permits a further means to exclude a
particular sanitizer. This gives finer grained control than
`COMPILER_RT_BUILD_SANITIZERS` which only gives an all or nothing control.
llvm-svn: 279253
Summary:
The Print() members might take optional access_size and bug_type
parameters to still be able to provide the same information
Reviewers: kcc, samsonov
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D23658
llvm-svn: 279237
When compiler-rt's CMake is not directly invoked, it will currently not call
project() and thus ASM will not be enabled.
We also don't need to put the .S files through the C compiler then.
Differential Revision: https://reviews.llvm.org/D23656
llvm-svn: 279215
Summary:
We are poisoning small allocas using store instruction from instrumented code.
For larger allocas we'd like to insert function calls instead of multiple stores.
PR27453
Reviewers: kcc, eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23616
llvm-svn: 279019
Summary: This value is never used.
Reviewers: kcc, eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23631
llvm-svn: 279010
Summary:
Replacement for part of D23518
This deals with global variable addresses.
(This commit is written on top of D23605, but can be applied by itself)
Reviewers: kcc, samsonov
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D23607
llvm-svn: 278959
Summary:
Replacement for part of D23518
This deals with stack addresses.
Reviewers: kcc, samsonov
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D23605
llvm-svn: 278958
Summary:
Replacement for part of D23518
This deals with heap addresses, and renames DescribeHeapAddress.
Requires D23520, which moves code around to make it accessible in asan_describers.cc (and still accessible in asan_report.cc if needed).
Reviewers: kcc, samsonov
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D23569
llvm-svn: 278917
Summary: This will allow for the sanitizers to be used when c++ abi is unavailable.
Reviewers: samsonov, beanz, pcc, rnk
Subscribers: llvm-commits, kubabrecka, compnerd, dberris
Differential Revision: https://reviews.llvm.org/D23376
llvm-svn: 278848
Clang added warning that taking the address of a packed struct member
possibly yields an unaligned pointer. This case is benign because
the pointer gets casted to an uptr and not used for unaligned accesses.
Add an intermediate cast to char* until this warning is improved (see
also https://reviews.llvm.org/D20561)
llvm-svn: 278835
Summary:
Replacement for part of D23518
Code refactoring to allow us to move some more DescribeAddressIf* functions to work by getting the structured information, and then printing it.
Reviewers: kcc, samsonov
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D23520
llvm-svn: 278820
Summary: This will allow for the sanitizers to be used when c++ abi is unavailable.
Reviewers: samsonov, beanz, pcc, rnk
Subscribers: llvm-commits, kubabrecka, compnerd, dberris
Differential Revision: https://reviews.llvm.org/D23376
llvm-svn: 278772
Summary: This will allow for the sanitizers to be used when c++ abi is unavailable.
Reviewers: samsonov, beanz, pcc, rnk
Subscribers: llvm-commits, kubabrecka, compnerd, dberris
Differential Revision: https://reviews.llvm.org/D23376
llvm-svn: 278764
Summary:
Replacement for part of D23518
This is the first patch to start reifying information about errors. It deals only with reifying shadow address-related information.
It will allow us to generate structures with all the relevant information for a given error so a debugger can get to them or they can be included in a core dump.
Reviewers: kcc, samsonov
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D23519
llvm-svn: 278718
This fixes a long-standing TODO by implementing a compiler check for supporting the _Atomic keyword. If the _Atomic keyword is supported by the compiler we should include it in the builtin library sources.
llvm-svn: 278454
With this change, the default behavior on error is to call abort()
instead of _exit(). This should help the OS to capture a tombstone of
the error.
RAM usage of the lit test suite goes up because of all the tombstone
gathering, so I'm limiting the parallelism of the test target.
Previously it was based on the number of the CPUs on the host
machine, which is definitely wrong.
llvm-svn: 278308
Current AArch64 {sig}{set,long}jmp interposing requires accessing glibc
private __pointer_chk_guard to get process xor mask to demangled the
internal {sig}jmp_buf function pointers.
It causes some packing issues, as described in gcc PR#71042 [1], and is
is not a godd practice to rely on a private glibc namespace (since ABI is
not meant to be stable).
This patch fixes it by changing how libtsan obtains the guarded pointer
value: at initialization a specific routine issues a setjmp call and
using the mangled function pointer and the original value derive the
random guarded pointer.
Checked on aarch64 39-bit VMA.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71042
llvm-svn: 278292
Summary:
While cross-compiling, a custom nm program may be required. This will also allow for the
use of llvm-nm if desired.
Reviewers: samsonov, beanz, compnerd, eugenis
Subscribers: kubabrecka, dberris, llvm-commits
Differential Revision: https://reviews.llvm.org/D23278
llvm-svn: 278187
The API is intended to be used by user to do fine
grained (per-region) control of profile dumping.
Differential Revision: http://reviews.llvm.org/D23106
llvm-svn: 278092
Summary:
Adds a new, generic, resizing hashtable data structure for use by esan
tools. No existing sanitizer hashtable is suitable for the use case for
most esan tools: we need non-fixed-size tables, parameterized keys and
payloads, and write access to payloads. The new hashtable uses either
simple internal or external mutex locking and supports custom hash and
comparision operators. The focus is on functionality, not performance, to
catalyze creation of a variety of tools. We can optimize the more
successful tools later.
Adds tests of the data structure.
Reviewers: aizatsky
Subscribers: vitalybuka, zhaoqin, kcc, eugenis, llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D22681
llvm-svn: 278024
Summary:
We also add one test (and the XRay testing infrastructure) to exercise
the patching and unpatching code. This uses the XRay API exported
through the headers as well, installing a custom log handler.
Depends on D23101 for the updated emitted code alignment for the
return/entry sleds.
Reviewers: rSerge, echristo, rnk
Subscribers: tberghammer, danalbert, srhines, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D23154
llvm-svn: 277971
Go back to intercepting kernel32!RaiseException, and only go for
ntdll!RtlRaiseException if that fails. Fixes throw_and_catch.cc test.
Work around an issue in LLVM's win64 epilogues. We end up with an
epilogue that looks like this, and it drives the Win64 unwinder crazy
until stack overflow:
call ill_cc!__asan_handle_no_return
xor eax,eax
add rsp,40h // epilogue starts
pop rbp // CSR
ud2 // Trap here
ret // Ret?
nop word ptr [rax+rax]
sub rsp,28h // Next function
Will file a PR soon.
llvm-svn: 277874
MSVC doesn't have an exact equivalent for __builtin_frame_address, but
_AddressOfReturnAddress() + sizeof(void*) should be equivalent for all
frames build with -fno-omit-frame-pointer.
llvm-svn: 277826
These are meant to only be included on certain targets. This only disables it
for Windows ARM for now. Ideally these would be conditionally included as
appropriate.
llvm-svn: 277777
Our Report implementation calls OutputDebugString, which calls
RtlRaiseException, which can re-enter back into the ASan runtime and
cause a hang.
Don't treat this special debugger-only exception code as a noreturn
event, since the stack won't really unwind all the way.
llvm-svn: 277763
Summary:
The sanitizer allocators can works with a dynamic address space
(i.e. specified with ~0ULL).
Unfortunately, the code was broken on GetMetadata and GetChunkIdx.
The current patch is moving the Win64 memory test to a dynamic
address space. There is a migration to move every concept to a
dynamic address space on windows.
To have a better coverage, the unittest are now testing
dynamic address space on other platforms too.
Reviewers: rnk, kcc
Subscribers: kubabrecka, dberris, llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D23170
llvm-svn: 277745
We now stash and restore the xmm registers in the trampolines so that
log handlers don't need to worry about clobbering these registers.
In response to comments in D21612.
Reviewers: rSerge, eugenis, echristo, rnk
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D23051
llvm-svn: 277683
Summary:
Respect the handle_sigill common flag and handle_segv flags while we're
at it.
We still handle signals/exceptions differently on Unix and Windows. The
installation process is tricky on Windows, and difficult to push down
into sanitizer_common without concerning it with the different
static/dynamic CRT models on Windows.
Reviewers: kcc, etienneb
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23098
llvm-svn: 277621
Anna Zaks