This adds a new helper that can be called from application code to
ensure that no mutexes are held on specific code paths. This is useful
for multiple scenarios, including ensuring no locks are held:
- at thread exit
- in peformance-critical code
- when a coroutine is suspended (can cause deadlocks)
See this discourse thread for more discussion:
https://discourse.llvm.org/t/add-threadsanitizer-check-to-prevent-coroutine-suspending-while-holding-a-lock-potential-deadlock/74051
This resubmits and fixes#69372 (was reverted because of build
breakage).
This also includes the followup change #71471 (to fix a land race).
Unclear what's going on here. I can reproduce the test failure at
https://lab.llvm.org/buildbot/#/builders/77/builds/31875 and well before
it as well.
Doesn't look like the device has changed, and I can also repro the
problem on Android 11 and Android 14. Disabling until further notice.
The new lit test fails, see comment on the PR. This also reverts
the follow-up commit, see below.
> This adds a new helper that can be called from application code to
> ensure that no mutexes are held on specific code paths. This is useful
> for multiple scenarios, including ensuring no locks are held:
>
> - at thread exit
> - in peformance-critical code
> - when a coroutine is suspended (can cause deadlocks)
>
> See this discourse thread for more discussion:
>
> https://discourse.llvm.org/t/add-threadsanitizer-check-to-prevent-coroutine-suspending-while-holding-a-lock-potential-deadlock/74051
This reverts commit bd841111f3.
This reverts commit 16a395b74d.
in https://github.com/llvm/llvm-project/pull/69625 @strega-nil added
cdecl to a huge number of sanitizer interface declarations. It looks
like she was racing against @kennyyu adding a tsan interface function. I
noticed this when merging in the latest changes from llvm/main and
corrected it.
Co-authored-by: Charlie Barto <Charles.Barto@microsoft.com>
All of the code assumes that when the pages are released, the entry is
zero'd, so use the correct function. On most systems, this does not
change anything.
This can be used to configure runtimes builds (instead of setting flags
individually), and we need to pass it down to the custom libc++ build
for it to work correctly.
Public headers intended for user code should not define `__has_feature`,
because this can break preprocessor checks done later in user code, e.g.
if they test `#ifdef __has_feature` to check for real support in the
compiler.
Replace the only use in the public header with a check for it being
supported before trying to use it. Define the fallback definition in the
internal headers, so that other internal sanitizer headers can continue
to use it as preferred.
This resolves a bug reported to GCC as https://gcc.gnu.org/PR109882
The system linker merges __objc_imageinfo flags values to select a
compatible set of flags using the minimum swift version and only
erroring on incompatible ABIs. Match that behaviour in the orc macho
platform. One wrinkle is that the JIT can add new objects after the
dylib is running code. In that case we only check for known incompatible
flags and ignore the swift version. It's too late to change the flags at
that point and swift version is unlikely to change runtime behaviour in
practice.
The Android LLVM build system builds the arm64 fuzzer lib without
HWASan, but then applications that enable HWASan can generated an object
file with a HWASan-ified version of some libc++ symbols (e.g.
`std::__1::piecewise_construct`). The linker can choose the HWASan-ified
definition, but then it cannot resolve the relocation from
libclang_rt.fuzzer-aarch64-android.a to this symbol because the high
bits of the address are unexpectedly set. This produces an error:
```
relocation R_AARCH64_ADR_PREL_PG_HI21 out of range
```
Fix this problem by linking a custom isolated libc++ into Android's
fuzzer library.
We need to pass through ANDROID_NATIVE_API_LEVEL so that the libc++ for
32-bit Android (API < 24) uses LLVM_FORCE_SMALLFILE_FOR_ANDROID.
The current TSan mappings for C/C++ on linux/x86_64 have 0.5TB
for low app mem, 1.5TB (1.17TB usable) for mid app mem and
1.5TB for high app mem.
This can get a bit cramped if the apps are huge, and/or (in the
case of mid/high app mem) with significant ASLR entropy
(default ASLR setting of 28-bits = 1TB).
This patch increases the mapping sizes to 2TB, 5TB, and 6TB for
the low, mid and high app regions respectively. This is compatible
with up to 30-bits of ASLR entropy. It is difficult to make the
mappings any larger, given the 44-bit pointer compression.
It also moves the heap region to avoid HeapEnd() overlapping with
the newly enlarged high app region.
For convenience, we now use kShadowAdd instead of kShadowXor for
this set of mappings. This should be roughly equivalent in
runtime performance.
MinGW mode can also use the MSVC/UCRT math functions. On ARM/ARM64,
mingw-w64 has always used the UCRT scalbn function. On x86, mingw-w64
recently changed to prefer the UCRT version for a large number of math
functions.
This is necessary for many projects which pass `/Gz` to their compiles,
which makes their default calling convention `__stdcall`.
(personal note, I _really_ wish there was a pragma for this)
compiler-rt/builtins doesn't depend on anything from the CRT but
currently links against it and embeds a `/defaultlib:msvcrt` in the
`.lib` file, forcing anyone linking against it to also link against that
specific CRT. This isn't necessary as the end user can just choose which
CRT they want to use independently.
Part 1 of 3. This includes the LLVM back-end processing and profile
reading/writing components. compiler-rt changes are included.
Differential Revision: https://reviews.llvm.org/D138846
This is a follow-up to 910a4bf5b.
1. __builtin_clz takes unsigned int, thus for uint16_t
src_rep_t_clz can't use it directly but should subtract 16
(leading 16 bits of the promoted argument are zero).
2. Fix (and simplify) clz_in_sig_frac.
Test plan: ninja check-compiler-rt
(extendhfsf2_test.c and extenddftf2_test.c)
BlockFrequencyInfo calculates block frequencies as Scaled64 numbers but as a last step converts them to unsigned 64bit integers (`BlockFrequency`). This improves the factors picked for this conversion so that:
* Avoid big numbers close to UINT64_MAX to avoid users overflowing/saturating when adding multiply frequencies together or when multiplying with integers. This leaves the topmost 10 bits unused to allow for some room.
* Spread the difference between hottest/coldest block as much as possible to increase precision.
* If the hot/cold spread cannot be represented loose precision at the lower end, but keep the frequencies at the upper end for hot blocks differentiable.
Use of long double can be error-prone since it could be one of 80-bit
extended precision float, IEEE 128-bit float, or IBM 128-bit float.
Instead use an explicit xf_float typedef for the remaining cases where
long double is being used in the implementation. This patch does not
touch
the PPC specializations which still use long double.
GCC provides these functions (e.g. __addtf3, etc.) in libgcc on x86_64.
Since Clang supports float128, we can also enable the existing code by
using float128 for fp_t if either __FLOAT128__ or __SIZEOF_FLOAT128__ is
defined instead of only supporting these builtins for platforms with
128-bit IEEE long doubles.
This commit defines a new tf_float typedef that matches a float with
attribute((mode(TF)) on each given architecture.
There are more tests that could be enabled for x86, but to keep the diff
smaller, I restricted test changes to ones that started failing as part
of this refactoring.
This change has been tested on x86 (natively) and
aarch64,powerpc64,riscv64 and sparc64 via qemu-user.
This supersedes https://reviews.llvm.org/D98261 and should also cover
the changes from https://github.com/llvm/llvm-project/pull/68041.
Prefer the new flag -lld-allow-duplicate-weak (which was added recently
in a67ae8c0fd), over the old -lldmingw.
The -lldmingw option enables a number of different behaviours, while
this test only is interested in one aspect of them.
This should allow making -lldmingw more strict with not enabling MSVC
specific behaviours like inferring lib directories automatically from
the environment, as being pursued in https://reviews.llvm.org/D144084.
This patch fixes:
compiler-rt/lib/builtins/int_to_fp_impl.inc:22:18: error: expression
is not an integer constant expression; folding it to a constant is a
GNU extension [-Werror,-Wgnu-folding-constant]
by using enum for constants.
These atomic primitives are required in order to implement the race
variants of the new And and Or operators in Go's sync/atomic package.
See Github issue golang/go#61395.
