Use Fuchsia's zx_system_get_features API to determine
whether LSE atomics are available on the machine.
Reviewed By: abrachet
Differential Revision: https://reviews.llvm.org/D118839
This has never really been used in practice. Fuchsia is moving
away from the support this requires, so don't use it.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D122500
After landing D121813 the binary size increase introduced by this change can be minimized by using --gc-sections link options. D121813 allows each individual callbacks to be optimized out if not used.
Reviewed By: vitalybuka, MaskRay
Differential Revision: https://reviews.llvm.org/D122407
Currently, we only print how threads involved in data race are created from their parent threads.
Add a runtime flag 'print_full_thread_history' to print thread creation stacks for the threads involved in the data race and their ancestors up to the main thread.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D122131
This patch updates the existing default no-arg constructor for
MemInfoBlock to explicitly initialize all members. Also add missing
DataTypeId initialization to the other constructor. These issues were
exposed by msan on patch D121179. With this patch D121179 builds cleanly
on msan.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D122260
For errno spoiling reports we only print the stack
where the signal handler is invoked. And the top
frame is the signal handler function, which is supposed
to give the info for debugging.
But in same cases the top frame can be some common thunk,
which does not give much info. E.g. for Go/cgo it's always
runtime.cgoSigtramp.
Print the signal number.
This is what we can easily gather and it may give at least
some hints regarding the issue.
Reviewed By: melver, vitalybuka
Differential Revision: https://reviews.llvm.org/D121979
Explicitly specify the class name to avoid selecting the wrong Run function, and inherit from the correct Test parent
Differential Revision: https://reviews.llvm.org/D121854
Tests can register multiple allocators, but only the first will initialize since it initializes the TSDRegistrySharedT. Then, destruction of subsequent allocator may end up unmapping a nullptr PrimaryBase with non-zero PrimarySize.
Differential Revision: https://reviews.llvm.org/D121858
-fsanitize-memory-use-after-dtor detects memory access after a
subobject is destroyed but its memory is not yet deallocated.
This is done by poisoning each object memory near the end of its destructor.
Subobjects (members and base classes) do this in their respective
destructors, and the parent class does the same for its members with
trivial destructors.
Inexplicably, base classes with trivial destructors are not handled at
all. This change fixes this oversight by adding the base class poisoning logic
to the parent class destructor.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D119300
After e5822ded562f, the call to LargeFunction can be optimized out, as x
is never accessed in main. This is causing the test to fail, because the
out-of-bounds access won't be executed.
Adding an extra read and returning the value should prevent the
optimizer from removing the call.
glibc >= 2.33 uses shared functions for stat family functions.
D111984 added support for non-64 bit variants but they
do not appear to be enough as we have been noticing msan
errors on 64-bit stat variants on Chrome OS.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D121652
If sanitizer cannot determine name of the module it
will use "<unknown module>". Then it can be suppressed
if needed.
Reviewed By: kda
Differential Revision: https://reviews.llvm.org/D121674
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
