The script uses llvm-link to link LLVM bitcode files.
5426da8ffa used -DLLVM_DISABLE_ASSEMBLY_FILES=ON
to ignore object files compiled from lib/Support/BLAKE3/*.S.
A better approach (which fits Bazel better) is to ignore non-bitcode files.
Reviewed By: akyrtzi
Differential Revision: https://reviews.llvm.org/D126728
sanitizer_intercept_overriders.h might override SANITIZER_INTERCEPT_CRYPT_R to
be undefined. There's no need to require crypt.h in that case.
(The motivation is that crypt() moved from glibc into its own package at some
point, which makes intercepting it and building with a single sysroot that
supports both pre-bullseye and post-bullseye a bit hairy.)
Differential Revision: https://reviews.llvm.org/D126696
Don't build atomic fetch nand libcall functions when the required
compiler builtin isn't available. Without this compiler-rt can't be
built with LLVM 13 or earlier.
Not building the libcall functions isn't optimal, but aligns with the
usecase in FreeBSD where compiler-rt from LLVM 14 is built with an LLVM
13 clang and no LLVM 14 clang is built.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D126710
Previous couple commits replaced SANITIZER_MAC with SANITIZER_APPLE in bulk.
This change will prompt anyone still trying to use SANITIZER_MAC to rename.
Differential Revision: https://reviews.llvm.org/D126577
rG6a9c719ee1be4562a9e16f2c71ac3e51ef9c4292 removed the backticks and this FIXME comment is no longer necessary.
Differential Revision: https://reviews.llvm.org/D126528
GCC recently started setting constructor priority on init_have_lse_atomics [1]
to avoid undefined initialization order with respect to other initializers,
causing accidental use of ll/sc intrinsics on targets where this was not
intended (which presents a minor performance problem as well as a
compatibility problem for users wanting to use the rr debugger). I initially
thought compiler-rt does not have the same issue as libgcc, since it looks
like we're already setting init priority on the constructor.
Unfortuantely, it does not appear that the HAVE_INIT_PRIORITY check is ever
performed anyway, so despite appearances the init priority was not actually
applied. Fix that by applying the init priority unconditionally. It has been
supported in clang ever since it was first introduced and in any case for
more than 14 years in both gcc and clang. MSVC is already excluded from this
code path and we're already using constructors with init priority elsewhere
in compiler-rt without additional check (though mostly in the sanitizer
runtime, which may have more narrow target support). Regardless, I believe
that for our supported compilers, if they support the constructor attribute,
they should also support init priorities.
While we're here, change the init priority from 101, which is the highest
priority for end user applications, to instead use one of the priority levels
reserved for implementations (1-100; lower integers are higher priority).
GCC ended up using `90`, so this commit aligns the value in compiler-rt
to the same value to ensure that there are no subtle initialization order
differences between libgcc and compiler-rt.
[1] 75c4e4909a
Differential Revision: https://reviews.llvm.org/D126424
Sanitizers ignore flag allocator_may_return_null=1 in strndup() calls.
When OOM is emulated, this causes to the unexpected crash.
Committed by pgousseau on behalf of "Kostyantyn Melnik, kmnls.kmnls@gmail.com"
Reviewed by: pgousseau
Differential Revision: https://reviews.llvm.org/D126452
The asserted order of THREAD_DESTROY and end of main() is not
guaranteed:
```
7: Hello from pthread
8: THREAD_TERMINATE 0x7e8000104000, self: 0x7e8000104000, name: child thread
9: Done.
10: THREAD_DESTROY 0x7e8000104000, self: 0x7e8000104000, name: child thread
```
Resulting in:
```
error: CHECK: expected string not found in input
// CHECK: Done.
```
Remove checking for "Done." (end of main()) to deflake this test.
Alternatively, we could use `CHECK-DAG`.
rdar://94036145
Addresses tests flakes described in
https://github.com/llvm/llvm-project/issues/55460
The test being updated can fail in FileCheck to match when given long
enough stack traces. This can be problematic when file system paths
become long enough to cause the majority of the long function name to
become truncated. We found in our CI that the truncated output would
often fail to match, thereby causing the test to fail when it should not.
Here we change the test to match on sybolizer output that should be more
reliable than matching inside the long function name.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D126102
This is a follow up to [Sanitizers][Darwin] Rename Apple macro SANITIZER_MAC -> SANITIZER_APPLE (D125816)
Performed a global search/replace as in title against LLVM sources
Differential Revision: https://reviews.llvm.org/D126263
While attempting to get the 64-bit lsan allocator working for Fuchsia, I
noticed this function would incorrectly return false for pointers returned
by the 64-bit allocator. On AArch64, this function attempts to get the VMA
size dynamically by counting the number of leading zeros from the function
frame address. This will fail if the frame address is significantly below an
allocated pointer (that is, the frame address has more leading zeros than an
allocated pointer). This is possible on Fuchsia and linux (when not called
from the initial thread stack).
It seems the intended use of this function is to speed up pointer scanning by
filtering out addresses that user code might not be able to access. Other
platforms this check is done on seem to hardcode the VMA size/shift, so it
seems appropriate to do this for aarch64 as well. This implies pointers on
aarch64 where the VMA size is <64 will pass through, but bad pointers will
still be caught by subsequent scan checks.
This patch also renames the function to something more fitting of what it's
trying to do.
Differential Revision: https://reviews.llvm.org/D123814
3bd112c720 fixed the fuzzing test on Linux, which, after
https://reviews.llvm.org/D125933, has one less branch. Turns out, on
Windows, that it still has the extra branch. I'm guessing that's because
exit() isn't known to be noreturn on Windows or something.
Either way, just make the test more tolerant.
https://reviews.llvm.org/D125933 improved some of LLVM's handling of
binary ORs, which meant we have one less conditional branch, because the
'if (Size > 5 && Data[5] == 'R')' and 'if (bits == 63)' branches are now
correctly folded.
Add a set of tests that iterate over possible combinations of
memory orders for lock free stack implementation.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D110552
Initial introduction of the new macro before obsoleting the old one - the old name was really confusing.
Also moved SANITIZER_WATCHOS and SANITIZER_TVOS definitions under common #if defined(__APPLE__) block
Differential Revision: https://reviews.llvm.org/D125816
The spinlock requires that lock-free operations are available;
otherwise, the implementation just calls itself. As discussed in
D120026.
Differential Revision: https://reviews.llvm.org/D123080
Thread create/destroy events are not guaranteed to belivered on the
parent thread, e.g., output from a CI job:
```
5: THREAD_CREATE 0x7e8000104000, self: 0x1102ebdc0, name: n/a
6: THREAD_START 0x7e8000104000, self: 0x7e8000104000, name: n/a
7: Hello from pthread
8: THREAD_TERMINATE 0x7e8000104000, self: 0x7e8000104000, name: child thread
9: THREAD_DESTROY 0x7e8000104000, self: 0x7e8000104000, name: child thread
```
Here, THREAD_DESTROY is delivered on the thread being destroyed.
rdar://92679941
On arm64 the read/write flag is set on the esr register.
Adding this flag check for arm64 enables a more accurate
print out for sanitizer signal reports and matches the
behavior on x86.
Fixes bug: https://bugs.llvm.org/show_bug.cgi?id=27543https://github.com/google/sanitizers/issues/653
These tests are now passing:
SanitizerCommon-asan-arm64-Darwin :: Posix/illegal_read_test.cpp
SanitizerCommon-asan-arm64-Darwin :: Posix/illegal_write_test.cpp
SanitizerCommon-asan-arm64e-Darwin :: Posix/illegal_read_test.cpp
SanitizerCommon-asan-arm64e-Darwin :: Posix/illegal_write_test.cpp
SanitizerCommon-tsan-arm64-Darwin :: Posix/illegal_read_test.cpp
SanitizerCommon-tsan-arm64-Darwin :: Posix/illegal_write_test.cpp
SanitizerCommon-tsan-arm64e-Darwin :: Posix/illegal_read_test.cpp
SanitizerCommon-tsan-arm64e-Darwin :: Posix/illegal_write_test.cpp
SanitizerCommon-ubsan-arm64-Darwin :: Posix/illegal_read_test.cpp
SanitizerCommon-ubsan-arm64-Darwin :: Posix/illegal_write_test.cpp
SanitizerCommon-ubsan-arm64e-Darwin :: Posix/illegal_read_test.cpp
SanitizerCommon-ubsan-arm64e-Darwin :: Posix/illegal_write_test.cpp
rdar://92104440
Differential Revision: https://reviews.llvm.org/D125416
This halves the size of LargeTest, dropping time to compile this
file locally from 14s to 5.5s. Hopefully this will also fix the
persistent timeouts in pre-merge checks.
Differential Revision: https://reviews.llvm.org/D124237
Also enable on X86_64.
The directory would change during the test execution. This should not
necessarily prevent us from indexing a directory (a user might
potentially do that if they specify a parent directory of the actual
symbols directory, and change unrelated files).
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D125143
Andrew Browne