Looks like armv8 can't handle a thousand threads, which GWP-ASan
requests when running a synchronised mutex test. Limiting this to 100 to
attempt to fix the build issue.
llvm-svn: 362163
Summary:
See D60593 for further information.
This patch pulls out the mutex implementation and the required definitions file.
We implement our own mutex for GWP-ASan currently, because:
1. We must be compatible with the sum of the most restrictive elements of the supporting allocator's build system. Current targets for GWP-ASan include Scudo (on Linux and Fuchsia), and bionic (on Android).
2. Scudo specifies `-nostdlib++ -nonodefaultlibs`, meaning we can't use `std::mutex` or `mtx_t`.
3. We can't use `sanitizer_common`'s mutex, as the supporting allocators cannot afford the extra maintenance (Android, Fuchsia) and code size (Fuchsia) overheads that this would incur.
In future, we would like to implement a shared base mutex for GWP-ASan, Scudo and sanitizer_common. This will likely happen when both GWP-ASan and Scudo standalone are not in the development phase, at which point they will have stable requirements.
Reviewers: vlad.tsyrklevich, morehouse, jfb
Reviewed By: morehouse
Subscribers: dexonsmith, srhines, cfe-commits, kubamracek, mgorny, cryptoad, jfb, #sanitizers, llvm-commits, vitalybuka, eugenis
Tags: #sanitizers, #llvm, #clang
Differential Revision: https://reviews.llvm.org/D61923
llvm-svn: 362138
In particular, don't call get_target_flags_for_arch() since that
will cause an error in some situations:
If DARWIN_iossim_ARCHS=i386;x86_64, DARWIN_osx_ARCHS=x86_64, and
DARWIN_iossym_SYSROOT isn't set (due to the simulator sysroot not being
available), then config-ix.cmake won't add i386 to COMPILER_RT_SUPPORTED_ARCH
but ubsan's test/CMakeLists.txt would call get_target_flags_for_arch()
with i386, which would then run into the error in
get_target_flags_for_arch().
Having these conditions isn't ideal. The background here is that we
configure our mac-hosted trunk bots all the same (so they all have the
same DARWIN_*_archs, and we don't easily know if a mac host bot is
targeting mac or ios at the place where we call cmake), but only the
ios-targeting bots have ios sysroots available.
This will hopefully unbreak that use case without impacting anything
else -- and it makes ubsan and asan test setup more alike.
llvm-svn: 362010
This should hopefully address the error we're seeing in older versions
of Clang.
Differential Revision: https://reviews.llvm.org/D62554
llvm-svn: 361909
- Fix cmake BOOL misspellings
- Set cmake policy for CMP0075 to NEW
As requested by smeenai I've compared CMAkeCache.txt in master with and
without this patch and the only changes are to the variable types I fixed:
$ diff build-b1-master/CMakeCache.txt build-b1-compiler-rt-fix-cmake-warnings/CMakeCache.txt
503c503
< COMPILER_RT_BAREMETAL_BUILD:STRING=OFF
---
> COMPILER_RT_BAREMETAL_BUILD:BOOL=OFF
550c550
< COMPILER_RT_HWASAN_WITH_INTERCEPTORS:STRING=ON
---
> COMPILER_RT_HWASAN_WITH_INTERCEPTORS:BOOL=ON
Patch by Wink Saville <wink@saville.com>.
Differential Revision: https://reviews.llvm.org/D61203
llvm-svn: 361866
This is a follow up to r361432, changing the layout of per-target
runtimes to more closely resemble multiarch. While before, we used
the following layout:
[RESOURCE_DIR]/<target>/lib/libclang_rt.<runtime>.<ext>
Now we use the following layout:
[RESOURCE_DIR]/lib/<target>/libclang_rt.<runtime>.<ext>
This also more closely resembles the existing "non-per-target" layout:
[RESOURCE_DIR]/lib/<os>/libclang_rt.<runtime>-<arch>.<ext>
This change will enable further simplification of the driver logic
in follow up changes.
Differential Revision: https://reviews.llvm.org/D62469
llvm-svn: 361784
Fuchsia has several exceptions which are merely informational and should
not be treated as crashes. This patch puts logic that read from the
exception port and handled the exception in a loop, and ignores
non-exceptions and informational exceptions.
Patch By: aarongreen
Differential Revision: https://reviews.llvm.org/D62226
llvm-svn: 361407
The only difference between __eqsf2 and __gtsf2 is whether they return
1 or -1 on NaN. Rather than duplicating all the code, use a macro to
define the function twice and use an argument to decide whether to
negate the return value.
Differential Revision: https://reviews.llvm.org/D61919
llvm-svn: 361207
Summary:
This CL introduces the 32 & 64-bit primary allocators, and associated
Local Cache. While the general idea is mostly similar to what exists
in sanitizer_common, it departs from the original code somewhat
significantly:
- the 64-bit primary no longer uses a free array at the end of a region
but uses batches of free blocks in region 0, allowing for a
convergence with the 32-bit primary behavior;
- as a result, there is only one (templated) local cache type for both
primary allocators, and memory reclaiming can be implemented similarly
for the 32-bit & 64-bit platforms;
- 64-bit primary regions are handled a bit differently: we do not
reserve 4TB of memory that we split, but reserve `NumClasses *
2^RegionSizeLog`, each region being offseted by a random number of
pages from its computed base. A side effect of this is that the 64-bit
primary works on 32-bit platform (I don't think we want to encourage
it but it's an interesting side effect);
Reviewers: vitalybuka, eugenis, morehouse, hctim
Reviewed By: morehouse
Subscribers: srhines, mgorny, delcypher, jfb, #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D61745
llvm-svn: 361159
This is needed when using compiler wrappers such as ccache or distcc
and should address the failure on clang-x86_64-debian-fast bot.
Differential Revision: https://reviews.llvm.org/D62104
llvm-svn: 361111
ShallowOOMDeepCrash.cpp may hit libFuzzer's RSS limit before the SIGUSR2
is delivered, causing the test to be flaky when bots are under load.
SleepOneSecondTest.cpp will keep running until the signal is delivered.
llvm-svn: 361048
Summary:
Removed dependency on c++ standard library. Some supporting allocators (namely Scudo on Fuchsia, and shortly, scudo standalone) has a hard requirement of no c++stdlib.
This patch updates the build system so that we don't have any c++ stdlib dependencies. It also will conveniently fix a racy build-order bug discrepency between GWP-ASan and libc++.
Reviewers: phosek, morehouse
Reviewed By: phosek, morehouse
Subscribers: kubamracek, mgorny, cryptoad, #sanitizers, llvm-commits, beanz, smeenai, vitalybuka
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D62048
llvm-svn: 360982
Summary:
Adds a call to __hwasan_handle_vfork(SP) at each landingpad entry.
Reusing __hwasan_handle_vfork instead of introducing a new runtime call
in order to be ABI-compatible with old runtime library.
Reviewers: pcc
Subscribers: kubamracek, hiraditya, #sanitizers, llvm-commits
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D61968
llvm-svn: 360959
pkill reads the process name as a pattern, not a raw name. This means
that if the process name contains + or other regex characters, pkill
fails.
llvm-svn: 360835
When MIPS 32-bit compiler-rt is building on 32-bit host or using 32-bit
`DLLVM_HOST_TRIPLE` the `_LARGEFILE_SOURCE` and the `_FILE_OFFSET_BITS=64`
macros defined by statements from the `HandleLLVMOptions.cmake`. In case
of building 32-bit libraries on 64-bit host using default host triple
these macros are not defined. As a result assertions check a consistency
between the `struct_kernel_stat_sz` constant and the `struct_kernel_stat_sz`
start to fail.
To resolve this problem and enable building both 32/64-bit versions
of MIPS compiler-rt libraries on 64-bit host at once always explicitly
define the `_LARGEFILE_SOURCE` and the `_FILE_OFFSET_BITS=64` macros
for MIPS 32-bit.
llvm-svn: 360825
Summary:
See D60593 for further information.
This patch slices off the PRNG implementation and the initial build files for GWP-ASan.
Reviewers: vlad.tsyrklevich, morehouse, vitalybuka
Reviewed By: morehouse
Subscribers: srhines, kubamracek, mgorny, #sanitizers, llvm-commits, cryptoad, eugenis
Tags: #sanitizers, #llvm
Differential Revision: https://reviews.llvm.org/D61867
llvm-svn: 360710
We're building with -std=c11 now (as opposed to -std=gnu11), so we can't
use GNU extensions and need to spell inline assembly as __asm__.
llvm-svn: 360503
The source uses C11 syntax such as comments and some compilers print
warnings without specifying this flag.
Differential Revision: https://reviews.llvm.org/D61797
llvm-svn: 360459
Mitch Phillips