Fix darwin interface test after D121464. asan_rtl_x86_64.S is not
available on Darwin.
Reviewed By: kstoimenov
Differential Revision: https://reviews.llvm.org/D121636
For ppc64 PIE, it seems that [0xa00000000000,0xc00000000000) may be occupied
which will lead to a segfault in certain kernel configurations
(clang-ppc64le-rhel). Use the `!kUsingConstantSpaceBeg` code path like Fuchsia.
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D121257
.thumb_func was not switching mode until [1]
so it did not show up but now that .thumb_func (without argument) is
switching mode, its causing build failures on armv6 ( rpi0 ) even when
build is explicitly asking for this file to be built with -marm (ARM
mode), therefore use DEFINE_COMPILERRT_FUNCTION macro to add function
header which considers arch and mode from compiler cmdline to decide if
the function is built using thumb mode or arm mode.
[1] https://reviews.llvm.org/D101975
Note that it also needs https://reviews.llvm.org/D99282
Reviewed By: peter.smith, MaskRay
Differential Revision: https://reviews.llvm.org/D104183
This clarifies that this is an LLVM specific variable and avoids
potential conflicts with other projects.
Differential Revision: https://reviews.llvm.org/D119918
This is a part of optimized callback reverts. This is needed to export the callbacks from the rt-asan libraries.
Reviewed By: kstoimenov
Differential Revision: https://reviews.llvm.org/D121464
At present compiler-rt cross compiles for armv6 ( -march=armv6 ) but includes
dmb instructions which are only available in armv7+ this causes SIGILL on
clang+compiler-rt compiled components on rpi0w platforms.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D99282
The false positive fixed by commit f831d6fc80
("tsan: fix false positive during fd close") still happens episodically
on the added more stressful test which does just open/close.
I don't have a coherent explanation as to what exactly happens
but the fix fixes the false positive on this test as well.
The issue may be related to lost writes during asynchronous MADV_DONTNEED.
I've debugged similar unexplainable false positive related to freed and
reused memory and at the time the only possible explanation I found is that
an asynchronous MADV_DONTNEED may lead to lost writes. That's why commit
302ec7b9bc ("tsan: add memory_limit_mb flag") added StopTheWorld around
the memory flush, but unfortunately the commit does not capture these findings.
Reviewed By: melver
Differential Revision: https://reviews.llvm.org/D121363
Use the correct types for OFF_T, __sanitizer_time_t and
__sanitizer_dirent and forward time_t related functions
to fix using compiler-rt with 32-bit musl libc.
Also redirect the time_t functions that are affected by
https://musl.libc.org/time64.html to use their 64-bit
ABI names.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D119358
follow up to 0a4dec6cc2.
add unsupported for s390 (SEGV)
restore line that s390 complains, so following asserts work.
Differential Revision: https://reviews.llvm.org/D121326
FdClose is a subjet to the same atomicity problem as MemoryRangeFreed
(memory state is not "monotoic" wrt race detection).
So we need to lock the thread slot in FdClose the same way we do
in MemoryRangeFreed.
This fixes the modified stress.cpp test.
Reviewed By: vitalybuka, melver
Differential Revision: https://reviews.llvm.org/D121143
This is useful when building a complete toolchain to ensure that CRT
is built after builtins but before the rest of the compiler-rt.
Differential Revision: https://reviews.llvm.org/D120682
This fixes a warning about comparing mismatched types. Since `mmap()` already returns a `void *` use that as the pointer type for comparison.
Reviewed By: kyulee, zequanwu
Differential Revision: https://reviews.llvm.org/D120945
Pass LIBCXX_HAS_PTHREAD_LIB, LIBCXX_HAS_RT_LIB and LIBCXXABI_HAS_PTHREAD_LIB
through to the custom lib++ builds so that libfuzzer doesn't end up with a .deplibs section that
links against those libraries when the variables are set to false.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D120946
The upstream project ships CMake rules for building vanilla gtest/gmock which conflict with the names chosen by LLVM. Since LLVM's build rules here are quite specific to LLVM, prefixing them to avoid collision is the right thing (i.e. there does not appear to be a path to letting someone *replace* LLVM's googletest with one they bring, so co-existence should be the goal).
This allows LLVM to be included with testing enabled within projects that themselves have a dependency on an official gtest release.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D120789
These are failing on our silent bot:
https://lab.llvm.org/staging/#/builders/162/builds/358
$ <run cmd>
main
foo
bar
baz
SanitizerCoverage: ./sanitizer_coverage_trace_pc_guard-dso.cpp.tmp.2122517.sancov: 2 PCs written
SanitizerCoverage: ./sanitizer_coverage_trace_pc_guard-dso.cpp.tmp_2.so.2122517.sancov: 1 PCs written
SanitizerCoverage: ./sanitizer_coverage_trace_pc_guard-dso.cpp.tmp_1.so.2122517.sancov: 1 PCs written
$ <sancov cmd>
ERROR: Coverage points in binary and .sancov file do not match.
Also reproduces if you build for Thumb on v8 hardware.
Doesn't fail when built with Arm only code so I guess the Thumb mode bit
in the PCs might be the issue.
Let `archive-aix-libatomic` accept additional argument to customize name of output atomic library.
Reviewed By: jsji
Differential Revision: https://reviews.llvm.org/D120534
See post-commit discussion on https://reviews.llvm.org/D120305.
This change breaks the clang-ppc64le-rhel buildbot, though
there is suspicion that it's an issue with the bot. The change
also had a larger than expected impact on compile-time and
code-size.
This reverts commit 3c4ed02698
and some followup changes.
This works with glibc crt1.o (its crt1.o is essentially Scrt1.o plus (if static
PIE is supported for the arch) _dl_relocate_static_pie) but looks wacky.
musl crt1.o is not built with an explicit -fno-pic/-fpie/-fpic. If it was built
with a non-default-pie GCC/Clang, the linker might complain about absolute
relocations referencing _init/_fini for the -pie link:
```
ld: error: relocation R_X86_64_32 cannot be used against symbol '_fini'; recompile with -fPIC
>>> defined in obj/crt/crt1.o
>>> referenced by crt1.c
>>> obj/crt/crt1.o:(_start_c)
```
Sanitizer coverage point should be the previous instruction PC of the
caller and the offset to the previous instruction might be different
on each CPU architecture.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D119233
Aligned new does not require size to be a multiple of alignment, so
memalign is the correct choice instead of aligned_alloc.
Fixes false reports for unaligned sizes.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D119161
Roman Lebedev