GCC is able to check that the signatures of the builtins are as expected
and this shows some incorrect signatures on ld80 platforms (i.e. x86).
The *tf* functions should take 128-bit arguments but until the latest fixes
they used 80-bit long double.
Differential Revision: https://reviews.llvm.org/D153814
For an odr-violation error due to a source file linked into two DSOs, or
one DSO and the main executable, it can be difficult to identify the DSO
name. Let's print the module name in the error report.
```
echo 'extern long var; int main() { return var; }' > a.cc
echo 'long var;' > b.cc
clang++ -fpic -fsanitize=address -shared b.cc -o b.so
clang++ -fsanitize=address a.cc b.cc ./b.so -o a
```
w/o this patch:
```
==1375386==ERROR: AddressSanitizer: odr-violation (0x56067cb06240):
[1] size=8 'var' b.cc
[2] size=8 'var' b.cc
...
```
w/ this patch:
```
==1375386==ERROR: AddressSanitizer: odr-violation (0x56067cb06240):
[1] size=8 'var' b.cc in /tmp/c/a
[2] size=8 'var' b.cc in ./b.so
```
In addition, update the `report_globals=2` message to include the module
name
```
==1451005==Added Global[0x7fcfe59ae040]: beg=0x7fcfe59ae140 size=8/32 name=var source=b.cc module=./b.so dyn_init=0 odr_indicator=0x55754f939260
```
This introduces an experimental flag 'test_only_replace_dlopen_main_program'. When enabled, this will replace dlopen(main program,...) with dlopen(NULL,...), which is the correct way to get a handle to the main program.
This can be useful when ASan is statically linked, since dladdr((void*)pthread_join) or similar will return the path to the main program.
Note that dlopen(main program,...) never ends well:
- PIE in recent glibc versions (glibc bugzilla 24323), or non-PIE: return an error
- PIE in current GRTE and older glibc: attempt to load the main program again, leading to reinitializing ASan and failing to remap the shadow memory.
---------
Co-authored-by: Thurston Dang <thurston@google.com>
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 bd841111f340a73eb23c1be70ff1be4c8a6afb0c.
This reverts commit 16a395b74d35c564f6f36ba4a167950a323badd9.
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.
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.
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.
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 a67ae8c0fd301a11e2a058e8035304cfc70a3e91), 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.
The check for dladdr1 for shared libc is too strict. Depending on how the system is setup we sometimes pick up the none generic lib name with the version string in it.
Update check to for libc to account for version string.
stack-uar.c is flaky (1 in 256 executions) because the random tag
may be zero (https://github.com/llvm/llvm-project/issues/69221).
This patch works around the issue in the same way as deep-recursion.c
(aa4dfd3736),
by falling back to a neighboring object, which must have a different
(non-zero) tag.
This patch also does a minor cleanup of the aforementioned
deep-recursion.c, for consistency with stack-uar.c.
Co-authored-by: Thurston Dang <thurston@google.com>
This fixes a buildbot breakage (e.g.,
https://lab.llvm.org/buildbot/#/builders/77/builds/31422/steps/21/logs/stdio)
that was caused by the introduction of this test
(ff1329e297).
Build error from buildbot:
/var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/compiler-rt/test/hwasan/TestCases/bcmp.cpp:18:10: error: use of undeclared identifier 'bcmp'
18 | return bcmp(p, a, size);
deep-recursion.c was disabled
(c007e0f66e)
because the test may get unlucky and end up with a zero-tagged variable,
leading to a false negative
(https://github.com/llvm/llvm-project/issues/69221).
This patch re-enables the test and adds a workaround: it checks
if the variable is zero-tagged, and if so, it will instead use the
neighboring variable, which must have a different (hence non-zero)
tag.
Fixing the stack allocation tagging is left as an exercise for the
reader. It is non-trivial because, even if the stackTagBase is
non-zero, tags for subsequent allocations in the stack frame may wrap
around to zero; working around this would require adding multiple
instructions to each alloca.
---------
Co-authored-by: Thurston Dang <thurston@google.com>
This patch implements __extendxftf2 (long double -> f128) and
__trunctfxf2 (f128 -> long double) on x86_64.
This is a preparation to unblock https://reviews.llvm.org/D53608,
We intentionally do not modify compiler-rt/lib/builtins/fp_lib.h in this
PR
(in particular, to limit the scope and avoid exposing other functions on
X86_64 in this PR).
Instead, TODOs were added to use fp_lib.h once it is available.
Test plan:
1. ninja check-compiler-rt (verified on X86_64 and on Aarch64)
In particular, new tests (extendxftf2_test.c and trunctfxf2_test.c) were
added.
2. compared the results of conversions with what other compilers (gcc)
produce.
After 144c5b6d58803a2d4a0fe92a0fe331ff0347dc3b, we still see this test
running in CI for aarch64-linux targets. This appears to be related to
the triple being `aarch64-unknown-linux-gnu`, or similar.
The bot link below includes 144c5b6d58803a2d4a0fe92a0fe331ff0347dc3b,
and fails the deep-recursion.c test, which should have been disabled.
https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-linux-arm64/b8767065085790662609/overview
The other 3 sanitizers (ASAN, TSAN and MSAN) all use
maybeMarkSanitizerLibraryCallNoBuiltin to make disable optimizations
which inline functions like memcmp for example. The lack of this
optimization was allowing ExpandMemCmpPass to convert a memcmp call to
inlined assembly and cause a false negative in HWASAN.
Implements for sv39 and sv48 VMA layout.
Userspace only has access to the bottom half of vma range. The top half
is used by kernel. There is no dedicated vsyscall or heap segment.
PIE program is allocated to start at TASK_SIZE/3*2. Maximum ASLR is
ARCH_MMAP_RND_BITS_MAX+PAGE_SHIFT=24+12=36 Loader, vdso and other
libraries are allocated below stack from the top.
Also change RestoreAddr to use 4 bits to accommodate MappingRiscv64_48
Reviewed by: MaskRay, dvyukov, asb, StephenFan, luismarques, jrtc27,
hiraditya, vitalybuka
Differential Revision: https://reviews.llvm.org/D145214
D145214 was reverted because one file was missing in the latest commit.
Luckily the file was there in the previous commit, probably the author
missed uploading that file with latest commit.
Co-authored-by: Alex Fan <alex.fan.q@gmail.com>
Functions with these attributes will be automatically called before
main() or after main() exits gracefully. In glibc environments, the
constructor function is passed the same arguments as main(), so that
signature is allowed. In all other environments, we require the function
to accept no arguments and either return `void` or `int`. The functions
must use the C calling convention. In C++ language modes, the functions
cannot be a nonstatic member function, or a consteval function.
Additionally, these reuse the same priority logic as the init_priority
attribute which explicitly reserved priorty values <= 100 or > 65535. So
we now diagnose use of reserved priorities the same as we do for the
init_priority attribute, but we downgrade the error to be a warning
which defaults to an error to ease use for implementers like compiler-rt
or libc.
This relands a633a3761fcbd0799426cbf5fbd7794961080e43 with fixes.
Functions with these attributes will be automatically called before
main() or after main() exits gracefully. In glibc environments, the
constructor function is passed the same arguments as main(), so that
signature is allowed. In all other environments, we require the function
to accept no arguments and either return `void` or `int`. The functions
must use the C calling convention. In C++ language modes, the functions
cannot be a nonstatic member function, or a consteval function.
Additionally, these reuse the same priority logic as the init_priority
attribute which explicitly reserved priorty values <= 100 or > 65535. So
we now diagnose use of reserved priorities the same as we do for the
init_priority attribute, but we downgrade the error to be a warning
which defaults to an error to ease use for implementers like compiler-rt
or libc.
This relands b4435104ca3904529723b0673cc0f624cf8c54e6 with fixes.
The -fsanitize=alignment implementation follows the model that we allow
forming unaligned pointers but disallow accessing unaligned pointers.
See [RFC: Enforcing pointer type alignment in Clang](https://lists.llvm.org/pipermail/llvm-dev/2016-January/094012.html)
for detail.
memcpy is a memory access and we require an `int *` argument to be aligned.
Similar to https://reviews.llvm.org/D9673 , emit -fsanitize=alignment check for
arguments of builtin memcpy and memmove functions to catch misaligned load like:
```
// Check the alignment of a but ignore the alignment of b
void unaligned_load(int *a, void *b) { memcpy(a, b, sizeof(*a)); }
```
For a reference parameter, we emit a -fsanitize=alignment check as well, which
can be optimized out by InstCombinePass. We rely on the call site
`TCK_ReferenceBinding` check instead.
```
// The alignment check of a will be optimized out.
void unaligned_load(int &a, void *b) { memcpy(&a, b, sizeof(a)); }
```
The diagnostic message looks like
```
runtime error: store to misaligned address [[PTR:0x[0-9a-f]*]] for type 'int *'
```
We could use a better message for memcpy, but we don't do it for now as it would
require a new check name like misaligned-pointer-use, which is probably not
necessary. *RFC: Enforcing pointer type alignment in Clang* is not well documented,
but this patch does not intend to change the that.
Technically builtin memset functions can be checked for -fsanitize=alignment as
well, but it does not seem too useful.
Implements for sv39 and sv48 VMA layout.
Userspace only has access to the bottom half of vma range. The top half is used by kernel.
There is no dedicated vsyscall or heap segment.
PIE program is allocated to start at TASK_SIZE/3*2. Maximum ASLR is ARCH_MMAP_RND_BITS_MAX+PAGE_SHIFT=24+12=36
Loader, vdso and other libraries are allocated below stack from the top.
Also change RestoreAddr to use 4 bits to accommodate MappingRiscv64_48
Reviewed by: MaskRay, dvyukov, asb, StephenFan, luismarques, jrtc27, hiraditya, vitalybuka
Differential Revision: https://reviews.llvm.org/D145214
The plan is to fix memcmp interceptor in HWASAN and remove the
unsupported statement at that time.
---------
Co-authored-by: Vitaly Buka <vitalybuka@gmail.com>
