Summary:
This first part just prepares the grounds for part 2 and doesn't add any new
functionality. It mostly consists of small refactors:
- move the `pthread.h` include higher as it will be used in the headers;
- use `errno.h` in `scudo_allocator.cpp` instead of the sanitizer one, update
the `errno` assignments accordingly (otherwise it creates conflicts on some
platforms due to `pthread.h` including `errno.h`);
- introduce and use `getCurrentTSD` and `setCurrentTSD` for the shared TSD
model code;
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: llvm-commits, srhines
Differential Revision: https://reviews.llvm.org/D38826
llvm-svn: 315583
The SanitizerCommon.ReservedAddressRangeUnmap test fails on Windows:
FAIL: SanitizerCommon-Unit :: ./Sanitizer-x86_64-Test.exe/SanitizerCommon.ReservedAddressRangeUnmap (34003 of 35554)
******************** TEST 'SanitizerCommon-Unit :: ./Sanitizer-x86_64-Test.exe/SanitizerCommon.ReservedAddressRangeUnmap' FAILED ********************
Note: Google Test filter = SanitizerCommon.ReservedAddressRangeUnmap
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from SanitizerCommon
[ RUN ] SanitizerCommon.ReservedAddressRangeUnmap
==3780==ERROR: SanitizerTool failed to deallocate 0x1000 (4096) bytes at address 0x0000000c3000 (error code: 487)
==3780==Sanitizer CHECK failed: E:\b\build\slave\win_upload_clang\build\src\third_party\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_win.cc:129 (("unable to unmap" && 0)) != (0) (0, 0)
********************
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
Testing Time: 299.76s
********************
Failing Tests (1):
SanitizerCommon-Unit :: ./Sanitizer-x86_64-Test.exe/SanitizerCommon.ReservedAddressRangeUnmap
> In Fuchsia, MmapNoAccess/MmapFixedOrDie are implemented using a global
> VMAR, which means that MmapNoAccess can only be called once. This works
> for the sanitizer allocator but *not* for the Scudo allocator.
>
> Hence, this changeset introduces a new ReservedAddressRange object to
> serve as the new API for these calls. In this changeset, the object
> still calls into the old Mmap implementations.
>
> The next changeset two changesets will convert the sanitizer and scudo
> allocators to use the new APIs, respectively. (ReservedAddressRange will
> replace the SecondaryHeader in Scudo.)
>
> Finally, a last changeset will update the Fuchsia implementation.
>
> Patch by Julia Hansbrough
>
> Differential Revision: https://reviews.llvm.org/D38437
llvm-svn: 315553
In Fuchsia, MmapNoAccess/MmapFixedOrDie are implemented using a global
VMAR, which means that MmapNoAccess can only be called once. This works
for the sanitizer allocator but *not* for the Scudo allocator.
Hence, this changeset introduces a new ReservedAddressRange object to
serve as the new API for these calls. In this changeset, the object
still calls into the old Mmap implementations.
The next changeset two changesets will convert the sanitizer and scudo
allocators to use the new APIs, respectively. (ReservedAddressRange will
replace the SecondaryHeader in Scudo.)
Finally, a last changeset will update the Fuchsia implementation.
Patch by Julia Hansbrough
Differential Revision: https://reviews.llvm.org/D38437
llvm-svn: 315533
Summary:
This is a new attempt at D38706, which had 2 issues.
The first one was that it broke TSan, because `sanitizer_errno.h` was not
directly included in `tsan_mman.cc`. This fixes the include.
The second one was that it broke the nolibc build, because `__errno_location`
couldn't be found. This adds the new .cc to the libcdep list instead of the
base one.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: kubamracek, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D38743
llvm-svn: 315509
In Fuchsia, MmapNoAccess/MmapFixedOrDie are implemented using a global
VMAR, which means that MmapNoAccess can only be called once. This works
for the sanitizer allocator but *not* for the Scudo allocator.
Hence, this changeset introduces a new ReservedAddressRange object to
serve as the new API for these calls. In this changeset, the object
still calls into the old Mmap implementations.
The next changeset two changesets will convert the sanitizer and scudo
allocators to use the new APIs, respectively. (ReservedAddressRange will
replace the SecondaryHeader in Scudo.)
Finally, a last changeset will update the Fuchsia implementation.
Patch by Julia Hansbrough
Differential Revision: https://reviews.llvm.org/D38759
llvm-svn: 315493
This is a very poorly named feature. I think originally it meant to cover linux only, but the use of it in msan
seems to be about any aarch64 platform. Anyway, this change should be NFC on everything except Android.
llvm-svn: 315389
Summary:
D38706 breaks tsan and the nolibc build.
Reverting while working on a fix.
Reviewers: alekseyshl
Subscribers: kubamracek, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D38739
llvm-svn: 315320
Summary:
The fact that `sanitizer_allocator_checks.h` is including `sanitizer_errno.h`
creates complications for future changes, where it would conflict with `errno.h`
definitions on Android and Fuchsia (macro redefinition).
By moving the portion that sets errno in the checks to a separate compilation
unit, we avoid the inclusion of the header there, which solves the issue.
Not that it is not vital to have that function in a header as it is called as a
result of an unlikely event, and doesn't need to be inlined.
Reviewers: alekseyshl
Reviewed By: alekseyshl
Subscribers: kubamracek, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D38706
llvm-svn: 315319
Fuchsia doesn't support signals, so don't use interceptors for signal or
sigaction.
Differential Revision: https://reviews.llvm.org/D38669
llvm-svn: 315227
Summary:
Since D37924 and D37925 were merged, it's now possible to specify
individual sanitizers or CFI modes in sanitizer blacklists. Update the
CFI blacklist entries to only apply to cfi-unrelated-cast checks.
Reviewers: eugenis, pcc
Reviewed By: eugenis
Subscribers: kcc
Differential Revision: https://reviews.llvm.org/D38385
llvm-svn: 315216
As a follow-up to r315142, this makes it possible to use ubsan with a
static runtime on Darwin. I've also added a new StandaloneStatic testing
configuration so the new setup can be tested.
llvm-svn: 315143
Summary:
Enable check-cfi and check-ubsan on Android.
Check-ubsan includes standalone and ubsan+asan, but not tsan or msan.
Cross-dso cfi tests are disabled for now.
Reviewers: vitalybuka, pcc
Subscribers: srhines, kubamracek, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D38608
llvm-svn: 315105
Replace a partial workaround for ld.bfd strangeness with the ultimate one: -fuse-ld=gold.
Reason: ld.bfd problem gets worse with libc++-based NDK toolchain.
llvm-svn: 315039
Summary:
It can be enabled via "-use_clang_coverage=1" flag. Reason for disabling:
libFuzzer resets Clang Counters and makes it impossible to generate coverage
report for a regular fuzz target (i.e. not standalone build).
Reviewers: kcc
Reviewed By: kcc
Subscribers: kcc
Differential Revision: https://reviews.llvm.org/D38604
llvm-svn: 315029
Summary:
Relanding D33859, which was reverted because it has "broken LOTS of
ARM/AArch64 bots for two days".
If it breaks something again, please provide some pointers to broken
bots, not just revert it, otherwise it's very hard to reason what's
wrong with this commit.
Whenever possible (Linux + glibc 2.16+), detect dynamic loader module by
its base address, not by the module name matching. The current name
matching approach fails on some configurations.
Reviewers: eugenis
Subscribers: aemerson, kubamracek, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D38600
llvm-svn: 315024
Summary:
This prevents the confusion when there are similarly named tests in
different configurations (like in test/sanitizer_common).
Reviewers: vitalybuka
Subscribers: srhines, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D38526
llvm-svn: 315011
Summary:
Run CFI tests on all targets current toolchain can target.
On multiarch Linux, this will run all CFI tests with -m32 and -m64.
Reviewers: pcc
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D38572
llvm-svn: 315001
Summary:
This change allows the XRay basic (naive) mode logging implementation to
start writing the payload entries through the arg1 logging handler. This
implementation writes out the records that the llvm-xray tool and the
trace reader library will start processing in D38550.
This introduces a new payload record type which logs the data through
the in-memory buffer. It uses the same size/alignment that the normal
XRay record entries use. We use a new record type to indicate these new
entries, so that the trace reader library in LLVM can start reading
these entries.
Depends on D38550.
Reviewers: pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38551
llvm-svn: 314968
Summary:
This change moves cxx-abi library in asan/ubsan/dd link command line
ahead of other libraries, such as pthread/rt/dl/c/gcc. Given that
cxx-abi may be the full libstdc++/libc++, it makes sense for it to be
ahead of libc and libgcc, at least.
The real motivation is Android, where in the arm32 NDK toolchain
libstdc++.a is actually a linker script that tries to sneak LLVM's
libunwind ahead of libgcc's. Wrong library order breaks unwinding.
Reviewers: srhines, danalbert
Subscribers: aemerson, kubamracek, mgorny, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D38520
llvm-svn: 314948
Summary:
This change removes the dependency on using a std::deque<...> for the
storage of the buffers in the buffer queue. We instead implement a
fixed-size circular buffer that's resilient to exhaustion, and preserves
the semantics of the BufferQueue.
We're moving away from using std::deque<...> for two reasons:
- We want to remove dependencies on the STL for data structures.
- We want the data structure we use to not require re-allocation in
the normal course of operation.
The internal implementation of the buffer queue uses heap-allocated
arrays that are initialized once when the BufferQueue is created, and
re-uses slots in the buffer array as buffers are returned in order.
We also change the lock used in the implementation to a spinlock
instead of a blocking mutex. We reason that since the release operations
now take very little time in the critical section, that a spinlock would
be appropriate.
This change is related to D38073.
This change is a re-submit with the following changes:
- Keeping track of the live buffers with a counter independent of the
pointers keeping track of the extents of the circular buffer.
- Additional documentation of what the data members are meant to
represent.
Reviewers: dblaikie, kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38119
llvm-svn: 314877
Summary:
When the XRay user calls the API to finish writing the log, the thread
which is calling the API still hasn't finished and therefore won't get
its trace written. Add a test for only the main thread to check this.
Reviewers: dberris
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38493
llvm-svn: 314875
r303188 removed all the uses of aliases for EABI functions from
compiler-rt, because some of them had mismatched calling conventions.
Obviously, we can't use aliases for functions which don't have the same
calling convention, but that's only an issue for floating-point
functions with the hardfloat ABI. In other cases, the stubs increase
size and reduce performance for no benefit.
This patch adds back the aliases, with appropriate checks to make sure
they're only used in cases where the calling convention matches.
llvm-svn: 314851
Summary:
This change removes the dependency on using a std::deque<...> for the
storage of the buffers in the buffer queue. We instead implement a
fixed-size circular buffer that's resilient to exhaustion, and preserves
the semantics of the BufferQueue.
We're moving away from using std::deque<...> for two reasons:
- We want to remove dependencies on the STL for data structures.
- We want the data structure we use to not require re-allocation in
the normal course of operation.
The internal implementation of the buffer queue uses heap-allocated
arrays that are initialized once when the BufferQueue is created, and
re-uses slots in the buffer array as buffers are returned in order.
We also change the lock used in the implementation to a spinlock
instead of a blocking mutex. We reason that since the release operations
now take very little time in the critical section, that a spinlock would
be appropriate.
This change is related to D38073.
Reviewers: dblaikie, kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38119
llvm-svn: 314766
Kostya Kortchinsky