As with Linux placce the Counters array in the __libfuzzer_extra_counters
section. This fixes the test on FreeBSD.
Reviewed by: vitalybuka
Differential Revision: https://reviews.llvm.org/D125902
Supports on Android but also from Linux 5.17
Reviewers: vitalybuka, eugenis
Reviewed-By: vitalybuka
Differential Revision: https://reviews.llvm.org/D127326
pthread_getaffinity_np (Linux `kernel/sched/core.c:sched_getaffinity`) fails
with EINVAL if 8*cpusetsize (constant in glibc: 1024) is smaller than
`nr_cpu_ids` (CONFIG_NR_CPUS, which is 2048 for several arch/powerpc/configs
configurations).
The build bot clang-ppc64le-linux-lnt seems to have a larger `nr_cpu_ids`.
Differential Revision: https://reviews.llvm.org/D127368
On FreeBSD AArch64 safestack needs to use __syscall to handle 64 bit arguments
Reviewed by: MaskRay, vitalybuka
Differential Revision: https://reviews.llvm.org/D125901
The stack pointer is stored in the second slot in the jump buffer on
AArch64. Use the correct slot value to read this rather than the
following register.
Reviewed by: melver
Differential Revision: https://reviews.llvm.org/D125762
As with 64 bit x86 use an offset in middle of the address space scaled up
to work with the full 48 bit space.
Reviewed by: MaskRay
Differential Revision: https://reviews.llvm.org/D125757
In D126580 we updated the test to reflect that there should always
be a full trace. However, some executions do not have symbolizer
information, so we will restore the original test until we can formulate
a more robust test.
Reviewed By: leonardchan
Differential Revision: https://reviews.llvm.org/D127334
This reverts commit b37d84aa8d.
This broke aarch64 asan builders for fuchsia. I accidentally changed the allocator
settings for fuchsia on aarch64 because the new asan allocator settings use:
```
// AArch64/SANITIZER_CAN_USE_ALLOCATOR64 is only for 42-bit VMA
// so no need to different values for different VMA.
const uptr kAllocatorSpace = 0x10000000000ULL;
const uptr kAllocatorSize = 0x10000000000ULL; // 3T.
typedef DefaultSizeClassMap SizeClassMap;
```
rather than reaching the final `#else` which would use fuchsia's lsan config.
I believe this should've been fixed with 4b15e665f8
which landed after this initial patch, but I reverted too early before I
saw the builder turn green again.
This updates existing asan allocator settings to use the same allocator settings as what lsan uses for platforms where they already match.
Differential Revision: https://reviews.llvm.org/D126927
This way downstream tools that read sanitizer output can differentiate between OOM errors
reported by sanitizers from other sanitizer errors.
Changes:
- Introduce ErrorIsOOM for checking if a platform-specific error code from an "mmap" is an OOM err.
- Add ReportOOMError which just prepends this error message to the start of a Report call.
- Replace some Reports for OOMs with calls to ReportOOMError.
- Update necessary tests.
Differential Revision: https://reviews.llvm.org/D127161
Repalce the fixed buffer in SymbolizerProcess with InternalScopedString,
and simply append to it when reading data.
Fixes#55460
Reviewed By: vitalybuka, leonardchan
Differential Revision: https://reviews.llvm.org/D126580
As there 3 intercepts that depend on libresolv, link tests in ./configure scripts may be confuse by the presence of resolv symbols (i.e. dn_expand) even with -lresolv and get a runtime error.
Android provides the functionality in libc.
https://reviews.llvm.org/D122849https://reviews.llvm.org/D126851
Reviewed By: eugenis, MaskRay
Differential Revision: https://reviews.llvm.org/D127145
ARM EHABI isn't signalled by any specific compiler builtin define,
but is implied by the lack of defines specifying any other
exception handling mechanism, `__USING_SJLJ_EXCEPTIONS__` or
`__ARM_DWARF_EH__`.
As Windows SEH also can be used for unwinding, check for the
`__SEH__` define too, in the same way.
This is the same change as 4a3722a2c3 /
D126866, applied on the compiler-rt builtins gcc_personality_v0
function.
Differential Revision: https://reviews.llvm.org/D126863
This interceptor only addresses writes to inputs. Reads of inputs are not checked.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D126851
The script uses llvm-link to link LLVM bitcode files.
5426da8ffa used -DLLVM_DISABLE_ASSEMBLY_FILES=ON
to ignore object files compiled from lib/Support/BLAKE3/*.S.
A better approach (which fits Bazel better) is to ignore non-bitcode files.
Reviewed By: akyrtzi
Differential Revision: https://reviews.llvm.org/D126728
sanitizer_intercept_overriders.h might override SANITIZER_INTERCEPT_CRYPT_R to
be undefined. There's no need to require crypt.h in that case.
(The motivation is that crypt() moved from glibc into its own package at some
point, which makes intercepting it and building with a single sysroot that
supports both pre-bullseye and post-bullseye a bit hairy.)
Differential Revision: https://reviews.llvm.org/D126696
Don't build atomic fetch nand libcall functions when the required
compiler builtin isn't available. Without this compiler-rt can't be
built with LLVM 13 or earlier.
Not building the libcall functions isn't optimal, but aligns with the
usecase in FreeBSD where compiler-rt from LLVM 14 is built with an LLVM
13 clang and no LLVM 14 clang is built.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D126710
Previous couple commits replaced SANITIZER_MAC with SANITIZER_APPLE in bulk.
This change will prompt anyone still trying to use SANITIZER_MAC to rename.
Differential Revision: https://reviews.llvm.org/D126577
rG6a9c719ee1be4562a9e16f2c71ac3e51ef9c4292 removed the backticks and this FIXME comment is no longer necessary.
Differential Revision: https://reviews.llvm.org/D126528
GCC recently started setting constructor priority on init_have_lse_atomics [1]
to avoid undefined initialization order with respect to other initializers,
causing accidental use of ll/sc intrinsics on targets where this was not
intended (which presents a minor performance problem as well as a
compatibility problem for users wanting to use the rr debugger). I initially
thought compiler-rt does not have the same issue as libgcc, since it looks
like we're already setting init priority on the constructor.
Unfortuantely, it does not appear that the HAVE_INIT_PRIORITY check is ever
performed anyway, so despite appearances the init priority was not actually
applied. Fix that by applying the init priority unconditionally. It has been
supported in clang ever since it was first introduced and in any case for
more than 14 years in both gcc and clang. MSVC is already excluded from this
code path and we're already using constructors with init priority elsewhere
in compiler-rt without additional check (though mostly in the sanitizer
runtime, which may have more narrow target support). Regardless, I believe
that for our supported compilers, if they support the constructor attribute,
they should also support init priorities.
While we're here, change the init priority from 101, which is the highest
priority for end user applications, to instead use one of the priority levels
reserved for implementations (1-100; lower integers are higher priority).
GCC ended up using `90`, so this commit aligns the value in compiler-rt
to the same value to ensure that there are no subtle initialization order
differences between libgcc and compiler-rt.
[1] 75c4e4909a
Differential Revision: https://reviews.llvm.org/D126424
Sanitizers ignore flag allocator_may_return_null=1 in strndup() calls.
When OOM is emulated, this causes to the unexpected crash.
Committed by pgousseau on behalf of "Kostyantyn Melnik, kmnls.kmnls@gmail.com"
Reviewed by: pgousseau
Differential Revision: https://reviews.llvm.org/D126452
The asserted order of THREAD_DESTROY and end of main() is not
guaranteed:
```
7: Hello from pthread
8: THREAD_TERMINATE 0x7e8000104000, self: 0x7e8000104000, name: child thread
9: Done.
10: THREAD_DESTROY 0x7e8000104000, self: 0x7e8000104000, name: child thread
```
Resulting in:
```
error: CHECK: expected string not found in input
// CHECK: Done.
```
Remove checking for "Done." (end of main()) to deflake this test.
Alternatively, we could use `CHECK-DAG`.
rdar://94036145
Addresses tests flakes described in
https://github.com/llvm/llvm-project/issues/55460
The test being updated can fail in FileCheck to match when given long
enough stack traces. This can be problematic when file system paths
become long enough to cause the majority of the long function name to
become truncated. We found in our CI that the truncated output would
often fail to match, thereby causing the test to fail when it should not.
Here we change the test to match on sybolizer output that should be more
reliable than matching inside the long function name.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D126102
This is a follow up to [Sanitizers][Darwin] Rename Apple macro SANITIZER_MAC -> SANITIZER_APPLE (D125816)
Performed a global search/replace as in title against LLVM sources
Differential Revision: https://reviews.llvm.org/D126263
Andrew Turner