| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 284059
|
|
|
|
|
|
|
|
| |
Fixes PR30329
Patch by Hans-Bernhard Broeker!
llvm-svn: 283955
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
This reverts commit b2af965b7924ad793b313996a96633bb72daf629.
Revert as these changes broke a Chromium buildbot.
llvm-svn: 283349
|
|
|
|
|
|
| |
is needed to support NVIDIA CUDA drivers. Unfortunately, I don't know how to test it properly with CUDA on a public build bot, so adding a test that emulates the CUDA behavior.
llvm-svn: 283270
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 283185
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Reviewed by eugenis offline, as reviews.llvm.org is down.
llvm-svn: 282805
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 282389
|
|
|
|
|
|
|
|
|
|
| |
ASan unit tests
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
|
|
|
|
|
|
|
|
|
|
| |
This patch is pretty the same as http://reviews.llvm.org/D20235 that we used
for ASan. Using the same hack for MSan fixes its initialization with newer
Glibc in use.
Differential Revision: https://reviews.llvm.org/D24736
llvm-svn: 282232
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: kcc, vitalybuka, eugenis
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D24777
llvm-svn: 282102
|
|
|
|
|
|
| |
sanitizer-windows bot
llvm-svn: 282096
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
https://reviews.llvm.org/D24771
llvm-svn: 282019
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Check bug_type for nullptr before calling internal_strcmp
Reviewers: kcc, vitalybuka, eugenis
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D24773
llvm-svn: 282012
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
__sanitizer_symbolize_global (to avoid conflict with another definition)
llvm-svn: 281902
|
|
|
|
|
|
| |
globals for now)
llvm-svn: 281886
|
|
|
|
|
|
| |
build
llvm-svn: 281747
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 281677
|
|
|
|
|
|
| |
Use the namespace in asan_win_dll_thunk.cc to fix the Windows bot.
llvm-svn: 281659
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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: Continue work on PR30351
Reviewers: vitalybuka, kcc, eugenis
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D24554
llvm-svn: 281593
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Continue work on PR30351
Reviewers: vitalybuka, kcc, eugenis
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D24552
llvm-svn: 281592
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Continue work on PR30351
Reviewers: vitalybuka, kcc, eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D24551
llvm-svn: 281591
|
|
|
|
| |
llvm-svn: 281558
|
|
|
|
| |
llvm-svn: 281548
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Continuing implementation mentioned in this thread: http://lists.llvm.org/pipermail/llvm-dev/2016-July/101933.html
Reviewers: kcc, eugenis, vitalybuka
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D24394
llvm-svn: 281444
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Continuing implementation mentioned in this thread: http://lists.llvm.org/pipermail/llvm-dev/2016-July/101933.html
Reviewers: kcc, eugenis, vitalybuka
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D24393
llvm-svn: 281443
|
|
|
|
|
|
|
| |
All known (to me) Android deployments are disabling this flag anyway.
The in-tree script (asan_device_setup) does that, too.
llvm-svn: 281410
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Continuing implementation mentioned in this thread: http://lists.llvm.org/pipermail/llvm-dev/2016-July/101933.html
Reviewers: kcc, eugenis, vitalybuka
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D24392
llvm-svn: 281392
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Continuing implementation mentioned in this thread: http://lists.llvm.org/pipermail/llvm-dev/2016-July/101933.html
Reviewers: kcc, eugenis, vitalybuka
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D24391
llvm-svn: 281391
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Continuing implementation mentioned in this thread: http://lists.llvm.org/pipermail/llvm-dev/2016-July/101933.html
Reviewers: kcc, eugenis, vitalybuka
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D24390
llvm-svn: 281390
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Continuing implementation mentioned in this thread: http://lists.llvm.org/pipermail/llvm-dev/2016-July/101933.html
Reviewers: kcc, eugenis, vitalybuka
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D24389
llvm-svn: 281389
|
|
|
|
|
|
|
| |
This uses the "very compact" size class mapping that fits in the
39-bit address space.
llvm-svn: 281371
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
consistent in constructor arguments and member order.
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of address.
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
|
|
|
|
|
|
| |
Previous patch added a #if which causes some unused identifier warnings.
llvm-svn: 280976
|
|
|
|
| |
llvm-svn: 280934
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Keep reifying other errors.
Reviewers: kcc, samsonov
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23873
llvm-svn: 280930
|