This fixes:
```
C:\git\llvm-project\compiler-rt\lib\orc\coff_platform.cpp(512): warning C4189: 'JDState': local variable is initialized but not referenced
```
Currently, almost all of the shared libraries of MIPS, rely on $t9
to get the address of current function, instead of PCREL instructions,
even on MIPSr6. So we have to set $t9 properly.
To get the address of preemptible function, we need the help of GOT.
MIPS/O32 has .cpload, which can help to generate 3 instructions to get GOT.
For __mips64, we can get GOT by:
lui $t8, %hi(%neg(%gp_rel(SANITIZER_STRINGIFY(TRAMPOLINE(func)))))
daddu $t8, $t8, $t9
daddiu $t8, $t8, %hi(%neg(%gp_rel(SANITIZER_STRINGIFY(TRAMPOLINE(func)))))
And then get the address of __interceptor_func, and jump to it
ld $t9, %got_disp(_interceptor" SANITIZER_STRINGIFY(func) ")($t8)
jr $t9
Fixes#74047
Co-authored-by: YunQiang Su <yunqiang.su@cipunited.com>
This variable was explicitly removed from the cache to ease transition
from existing build directories but that breaks passing
COMPILER_RT_BUILD_CRT=OFF on the command line. I was surprised to see
the CRT builds being run for my builtins-only build config (I noticed
because one of the tests was failing despite having `REQUIRES: crt`).
If I pass `-DCOMPILER_RT_BUILD_CRT=OFF` to cmake and add some prints
around the `unset` statement it shows the following:
```
-- before unset(): COMPILER_RT_BUILD_CRT=OFF
-- after unset: COMPILER_RT_BUILD_CRT=
-- after cmake_dependent_option COMPILER_RT_BUILD_CRT=ON
```
Drop this temporary workaround now that over 6 months have passed.
It turns out this works _mostly_ fine, even when mixing debug versions
of asan with programs built with the release runtime. Using /MT (or
/MTd) with a dynamically linked asan has never really worked that well,
and I am planning on opening a PR that will completely remove the
static-asan configuration for windows and make programs linked with the
static CRT/runtime work with the DLL version of asan. This is better
than the current situation because the static linked version of asan
doesn't work well on windows if there are multiple DLLs in the process
using it.
The check for building asan with only /MD or /MT has been removed. It
was in AsanDoesNotSupportStaticLinkage, but was checking for debug CRTs,
not static linkage. The kind of static linkage this function is supposed
to check for (on linux for example) doesn't really exist on windows.
Note: There is one outstanding issue with this approach, if you mix a
/MDd DLLs and /MD dlls in the same process then the "real" function
called by asan interceptors will be the same for calls from both
contexts, potentially screwing up things like errno. This only happens
if you mix /MD and /MDd in the same process, because otherwise asan
won't find functions from both runtimes to intercept. We are working on
a fix for this, and it mainly hits with the CRT functions exported from
both ucrtbase and ntdll.
This change is being upstreamed from Microsoft's fork.
Forward fix for https://github.com/llvm/llvm-project/pull/75256
The process for MmapAlignedOrDieOnFatalError involves trimming the start
and end of a mapping to ensure it's aligned correctly. This invloves
calling zx_vmar_map again but overwriting a part of the original vmar
which involves a call to zx_object_get_info(ZX_INFO_VMAR). After
https://github.com/llvm/llvm-project/pull/75256, we unconditionally
called this on gSanitizerHeapVmar but this can lead to a
ZX_ERR_INVALID_ARGS if the prior mapping was on the root vmar.
This can be fixed by also returning the vmar we did the last mapping to
and using that for followup operations that specifically involve the
same vmar. This way we don't have to try each syscall for both vmars.
https://github.com/llvm/llvm-project/pull/68132 ended up removing
__multc3 & __divtc3 from compiler-rt library builds that have
QUAD_PRECISION but not TF_MODE due to missing int128 support. I added support for QUAD_PRECISION to
use the native hex float long double representation.
---------
Co-authored-by: Alexander Richardson <mail@alexrichardson.me>
In an effort to reduce more mmap fragmentation, allocate a large enough
vmar where we can map sanitizer internals via DoAnonymousMmap. Objects
being mapped here include asan's FakeStack, LowLevelAllocator mappings,
the primary allocator's TwoLevelMap, InternalMmapVector, StackStore, and
asan's thread internals. The vmar is large enough to hold the total size
of these objects seen in a "typical" process lifetime. If the vmar is
full, it will fallback to mapping in the root vmar.
StackSafetyAnalysis determines whether stack-allocated variables are
guaranteed to be safe from memory access bugs and enables the removal of
certain unneeded instrumentations.
(hwasan enables StackSafetyAnalysis in https://reviews.llvm.org/D108381)
In a release build of clang, text sections are 9% smaller.
Test updates:
* asan-stack-safety.ll: test the -asan-use-stack-safety=1 default
* lifetime-uar-uas.ll: switch to an indexed store to prevent
StackSafetyAnalysis from optimizing out instrumentation for %c
* alloca_vla_interact.cpp: add a load to prevent StackSafetyAnalysis
from optimizing out `__asan_alloca_poison` for the VLA `array`
* scariness_score_test.cpp: add -asan-use-stack-safety=0 to make a load
of a `__asan_poison_memory_region`-poisoned local variable fail as
intended.
* other .ll tests: add -asan-use-stack-safety=0
Reviewed By: kstoimenov
Pull Request: https://github.com/llvm/llvm-project/pull/77210
Calling one of pthread join/detach interceptor on an already
joined/detached thread causes asserts such as:
AddressSanitizer: CHECK failed: sanitizer_thread_arg_retval.cpp:56
"((t)) != (0)" (0x0, 0x0) (tid=1236094)
#0 0x555555634f8b in __asan::CheckUnwind()
compiler-rt/lib/asan/asan_rtl.cpp:69:3
#1 0x55555564e06e in __sanitizer::CheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long)
compiler-rt/lib/sanitizer_common/sanitizer_termination.cpp:86:24
#2 0x5555556491df in __sanitizer::ThreadArgRetval::BeforeJoin(unsigned
long) const
compiler-rt/lib/sanitizer_common/sanitizer_thread_arg_retval.cpp:56:3
#3 0x5555556198ed in Join<___interceptor_pthread_tryjoin_np(void*,
void**)::<lambda()> >
compiler-rt/lib/asan/../sanitizer_common/sanitizer_thread_arg_retval.h:74:26
#4 0x5555556198ed in pthread_tryjoin_np
compiler-rt/lib/asan/asan_interceptors.cpp:311:29
The assert are replaced by error codes.
StackSafetyAnalysis determines whether stack-allocated variables are
guaranteed to be safe from memory access bugs and enables the removal of
certain unneeded instrumentations.
(hwasan enables StackSafetyAnalysis in https://reviews.llvm.org/D108381)
Test updates:
* asan-stack-safety.ll: test the -asan-use-stack-safety=1 default
* lifetime-uar-uas.ll: switch to an indexed store to prevent
StackSafetyAnalysis from optimizing out instrumentation for %c
* alloca_vla_interact.cpp: add a load to prevent StackSafetyAnalysis
from optimizing out `__asan_alloca_poison` for the VLA `array`
* scariness_score_test.cpp: add -asan-use-stack-safety=0 to make a load
of a `__asan_poison_memory_region`-poisoned local variable fail as
intended.
* other .ll tests: add -asan-use-stack-safety=0
Reviewers: kstoimenov, eugenis, vitalybuka
Reviewed By: kstoimenov
Pull Request: https://github.com/llvm/llvm-project/pull/77210
To enable the condition variable, you have to define both
UseConditionVariable and the ConditionVariableT. Otherwise, it'll be
disabled. However, you may want to disable the condition variable by
setting UseConditionVariable=false, for example, while measuring the
performance and you want to turn it off temporarily. Instead of
requiring the removal of the variable, examining its value makes more
sense.
It is desirable to be able to configure the `-mmacosx-version-min` flag
for the sanitizers, but this flag was never made a CACHE variable in
cmake.
By doing this, it will allow developers to select different minimum
versions, which results in different interceptors being enabled or
disabled on their platforms. This version can now persist between cmake
runs, so it can be remembered by cmake, and edited in the cache file.
This PR exposes four PGO functions
- `__llvm_profile_set_filename`
- `__llvm_profile_reset_counters`,
- `__llvm_profile_dump`
- `__llvm_orderfile_dump`
to user programs through the new header `instr_prof_interface.h` under
`compiler-rt/include/profile`. This way, the user can include the header
`profile/instr_prof_interface.h` to introduce these four names to their
programs.
Additionally, this PR defines macro `__LLVM_INSTR_PROFILE_GENERATE` when
the program is compiled with profile generation, and defines macro
`__LLVM_INSTR_PROFILE_USE` when the program is compiled with profile
use. `__LLVM_INSTR_PROFILE_GENERATE` together with
`instr_prof_interface.h` define the PGO functions only when the program
is compiled with profile generation. When profile generation is off,
these PGO functions are defined away and leave no trace in the user's
program.
Background:
https://discourse.llvm.org/t/pgo-are-the-llvm-profile-functions-stable-c-apis-across-llvm-releases/75832
Change the format of IRPGO counter names to
`[<filepath>;]<mangled-name>` which is computed by
`GlobalValue::getGlobalIdentifier()` to fix#74565.
In fe051934cbb0aaf25d960d7d45305135635d650b
(https://reviews.llvm.org/D156569) the format of IRPGO counter names was
changed to be `[<filepath>;]<linkage-name>` where `<linkage-name>` is
basically `F.getName()` with some prefix, e.g., `_` or `l_` on Mach-O
(yes, it is confusing that `<linkage-name>` is computed with
`Mangler().getNameWithPrefix()` while `<mangled-name>` is just
`F.getName()`). We discovered in #74565 that this causes some missed
import issues on some targets and #74008 is a partial fix.
Since `<mangled-name>` may not match the `<linkage-name>` on some
targets like Mach-O, we will need to post-process the output of
`llvm-profdata order` before passing to the linker via `-order_file`.
Profiles generated after fe051934cbb0aaf25d960d7d45305135635d650b will
become stale after this diff, but I think this is acceptable since that
patch landed after the LLVM 18 cut which hasn't been released yet.
When merging instrFDO profiles with afdo profile as supplementary, instrFDO counters for static functions are stored with function's PGO name (with filename.cpp; prefix).
- This pull request fixes the delimiter used when a PGO function name is 'normalized' for AFDO look-up.
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.
Temporarily fix for issue #76545
Hwasan does not attach tags to @llvm.dbg.assign. It's not clear if we
can attach tags to @llvm.dbg.assign.
For now we just disable the path replacing llvm.dbg.declare with
llvm.dbg.assign.
It may reduce the quality of interactive debugging with HWASAN, but
usually it's
a smaller priority for sanitizers than the quality if reports.
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.
