This migrates the dylib manager lookup and related APIs to replace
ExecutorAddress with ExecutorSymbolDef so that in the future we can
model JITSymbolFlags for these symbols. The current change should be NFC
as we are only setting the Exported symbol flag.
After 05a4212cc76d a number of long double related declarations are
enabled in `int_types.h`, whenever the CPU architecture and platform
support it. However, this does not work with FreeBSD's standalone
environment, which disallows any use of floating point.
In add98b246290 this was made conditional with `CRT_HAS_FLOATING_POINT`,
so extend the block guarded by that define to include all floating point
related declarations.
a15532d7647a8a4b7fd2889bd97f6f72f273c4bf landed a patch that added
support for detecting more AMD znver2 CPUs and cleaned up some of the
surrounding code, including the znver3 detection. Since one model group
is 00h-0fh, I adjusted the check to include checking if the value is
greater than zero. Since the value is unsigned, this is always true and
gcc warns on it. This patch removes the comparison with zero to get rid
of the compiler warning.
Most asan tests `FAIL` on FreeBSD 14.0/amd64 with
```
==17651==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
```
With `ASAN_OPTIONS=verbosity=2` one sees:
```
==4880==info->dlpi_name = [vdso] info->dlpi_addr = 0xffffe780
==4880==info->dlpi_name = lib/clang/18/lib/freebsd/libclang_rt.asan-i386.so info->dlpi_addr = 0x2808a000
```
Ignoring the vDSO as on Linux fixes this.
Tested on `amd64-pc-freebsd14.0`.
[builtins] Fix CPU feature detection for FreeBSD on AArch64
This is a follow-up to #75635 which broke the build for FreeBSD on
AArch64:
```
compiler-rt/lib/builtins/cpu_model/aarch64/lse_atomics/freebsd.inc:3:16: error: call to undeclared function 'elf_aux_info'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
3 | int result = elf_aux_info(AT_HWCAP, &hwcap, sizeof hwcap);
| ^
```
Using `elf_aux_info()` requires including `<sys/auxv.h>` first. To
prevent redeclaration issues with `hwcap.inc` attempting to define
`HWCAP_xxx` macros before `<sys/auxv.h>` does so, include `<sys/auxv.h>`
before any of the `.inc` files on FreeBSD.
Locking StackDepotBase fully is very expensive, as 2^20 buckets needs to
be locked. Not locking, but only unlocking buckets, needed to be
unlocked to avoid deadlocks, increases a chance of data race, when the
value with same hash can be inserted into table twice, but one is lost.
However this is just a small additional memory usage by forked process.
Similar to b9935bb02a50, but also apply a similar change to
ACCESS_CHECK_ADD.
If ASAN_SHADOW_OFFSET_CONST cannot be encoded as a displacement, switch
to `movabsq` and the register offset variant of cmp.
This is a follow up to #75635 which broke the build on Fuchsia. We don't
support ifunc on Fuchsia so we shouldn't define __init_cpu_features. For
__init_cpu_features_resolver we have to use _zx_system_get_features as a
Zircon native solution.
This is preparation for performance optimization.
We need to highlight that this is very specific lock, and should not be
used for other purposes.
Add `fork_child` parameter to distinguish processes after fork.
`tsan_interceptors_posix.cpp` doesn't compile on FreeBSD 14.0/amd64:
```
In file included from /vol/llvm/src/llvm-project/local-freebsd/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:25:
/vol/llvm/src/llvm-project/local-freebsd/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp: In function ‘void __tsan::InitializeInterceptors()’:
/vol/llvm/src/llvm-project/local-freebsd/compiler-rt/lib/tsan/rtl/../../interception/interception.h:243:25: error: ‘real_pthread_mutex_clocklock’ is not a member of ‘__interception’; did you mean ‘real_pthread_mutex_unlock’?
```
Fixed by wrapping the `TSAN_INTERCEPT` invocation with `SANITIZER_LINUX`
as is already done for the interceptor definition.
Tested on `amd64-pc-freebsd14.0`.
This patch adds proper detection support for more znver2 CPUs.
Specifically, this adds in support for CPUs codenamed Renoir, Lucienne,
and Mendocino.
This was originally proposedfor Renoir in
https://reviews.llvm.org/D96220 and
got approved, but slipped through the cracks. However, there is still a
demand for this feature.
In addition to adding support for more znver2 CPUs, this patch also includes
some additional refactoring and comments related to cpu model
information for zen CPUs.
Fixes https://github.com/llvm/llvm-project/issues/74934.
There is an assumption that we dont need to to mix sanitizer with
symbolizer from different LLVM revison. If so we can detect it by
`__sanitizer_symbolize_code` and assume that the rest is present.
If a sanitizer suppression file can not be parsed, add the supported
suppression types to the error message.
See https://github.com/llvm/llvm-project/issues/72060.
---------
Co-authored-by: Vitaly Buka <vitalybuka@gmail.com>
Fix#57086: when ASAN_SHADOW_OFFSET_CONST >= 0x80000000 (FreeBSD,
NetBSD, etc), `movsbl ASAN_SHADOW_OFFSET_CONST(%r10),%r10d` has an
invalid displacement (not representable as a signed 32-bit integer),
which will be diagnosed by GNU assembler.
```
% cat a.s
movsbl 0x80000000(%r10),%r10d
% as a.s
a.s: Assembler messages:
a.s:1: Error: 0x80000000 out of range of signed 32bit displacement
% clang -c a.s
```
The integrated assembler after #75747 will diagnose the invalid
displacement as well.
```
% clang -c a.s
a.s:1:19: error: displacement 2147483648 is not within [-2147483648, 2147483647]
movsbl 0x80000000(%r10),%r10d
^
```
If ASAN_SHADOW_OFFSET_CONST cannot be encoded as a displacement, switch
to `movabsq+movsbl`.
