`sanitizer_procmaps_solaris.cpp` currently uses `#undef
_FILE_OFFSET_BITS` to hack around the fact that old versions of Solaris
`<procfs.h>` don't work in a largefile environment:
```
/usr/include/sys/procfs.h:42:2: error: #error "Cannot use procfs in the large file compilation environment"
42 | #error "Cannot use procfs in the large file compilation environment"
| ^~~~~
```
However, this is no longer an issue on either Solaris 11.4 or Illumos.
The workaround only existed for the benefit of Solaris 11.3. While that
had never been supported by LLVM, the sanitizer runtime libs were
imported into GCC's `libsanitzer`. With the removal of Solaris 11.3
support in GCC 15, this is no longer an issue and the workaround can be
removed.
Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11`.
Currently, if TSan needs to disable ASLR but is unable to do so, it
aborts with a cryptic message:
```
ThreadSanitizer: CHECK failed: tsan_platform_linux.cpp:290 "((personality(old_personality | ADDR_NO_RANDOMIZE))) != ((-1))"
```
and a segfault
(https://github.com/google/sanitizers/issues/837#issuecomment-2939267531).
This patch replaces the CHECK with more user-friendly diagnostics and
suggestions via printf, followed by Die().
The existing implementations, written in assembly, make use of unaligned
accesses for performance reasons. They are not compatible with strict
aligned configurations, i.e. with `-mno-unaligned-access`.
If the functions are used in this scenario, an exception is raised due
to unaligned memory accesses.
This patch reintroduces vanilla implementations for these functions to
be used in strictly aligned configurations. The actual code is largely
based on the code from https://github.com/llvm/llvm-project/pull/77496
This changes the save/restore procedures to save/restore registers one
by one - to match the stack alignment for the ILP32E/LP64E ABIs, rather
than the larger batches of the conventional ABIs. The implementations of
the save routines are not tail-shared, to reduce the number of
instructions. I think this also helps code size but I need to check this
again.
I would expect (but haven't measured) that the majority of functions
compiled for the ILP32E/LP64E ABIs will in fact use both callee-saved
registers, and therefore there are still savings to be had, but I think
those can come later, with more data (especially if those changes are
just to the instruction sequences we use to save the registers, rather
than the number and alignment of how this is done).
This is a potential break for all of the ILP32E/LP64E ABI - we may
instead have to teach the compiler to emit the CFI information correctly
for the grouping we already have implemented (because that grouping
matches GCC). It depends on how intentional we think the grouping is in
the original ILP32E/LP64E save/restore implementation was, and whether
we think we can fix that now.
Created for Wine's memset by clang or mingw-gcc,
the latter places it quite at the start of the function:
```
0x00006ffffb67e210 <memset+0>: 0f b6 d2 movzbl %dl,%edx
0x00006ffffb67e213 <memset+3>: 48 b8 01 01 01 01 01 01 01 01 movabs $0x101010101010101,%rax
```
`3200 uint64_t v = 0x101010101010101ull * (unsigned char)c;`
290fd532ee/dlls/msvcrt/string.c (L3200)
Support `%` patterns in sanitizer report paths, similar to the patterns
supported in IRPGO
4bf67cdf02/compiler-rt/lib/profile/InstrProfilingFile.c (L999-L1017)
* `%%` becomes `%`
* `%H` expands to the environment variable `HOME`
* `%t` expands to the environment variable `TMPDIR`
* `%p` expands to the process ID (PID)
In particular, the `%H` pattern is useful to resolve the home directory
at runtime, which is not possible before this PR.
Also, avoid using `Report()` before the report path has been set.
Inside `getCurFilename`, there is this code snippit
```
if (!lprofCurFilename.FilenamePat || !lprofCurFilename.FilenamePat[0])
return 0;
```
If this is true, we return `"\0"`, but would leak the memory in
`FilenameBuf`.
This pull request adds a free before then to properly free the memory.
There was already a check that we allocated memory, so there is no need
to worry about freeing unallocated memory.
The XRay interface header uses no C++ specific features aside from using
the `std` namespace and including the C++ variant of C headers. Yet,
these changes prevent using `xray_interface.h` in external tools relying
on C for different reasons. Make this header C compliant by using C
headers, removing the `std` namespace from `std::size_t` and guard
`extern "C"`.
To make sure that further changes to not break the interface
accidentally, port one test from C++ to C. This requires the C23
standard to officially support the attribute syntax used in this test
case.
Note that this only resolves this issue for `xray_interface.h`.
`xray_records.h` is also not C compliant, but requires more work to
port.
Fixes#139902
Signed-off-by: Jan André Reuter <j.reuter@fz-juelich.de>
While the current test exercised the deadlock behavior prior to #131756,
deadlock still can occur intermittently. Since this results in test
flakes in CI, we disable this test until the locking behavior can be
fixed in the runtime. See #140646 for details.
Previously we would add any ELF that contained a build id regardless
whether the ELF contained symbols or not. This works for Android since
soong will strip the symbols into a new directory. However other
build systems, like BUCK, will write the stripped file in the same
directory as the unstripped file. This would cause the hwasan_symbolize
script sometimes add then stripped ELF to its index and ignore the
symbolized ELF. The logic has now been changed to only add ELFs that
contain symbols to the index. If two symbolized ELFs are encountered
with the same build id, we now exit out with an error.
Fixes#135966
---------
Co-authored-by: Stefan Bossbaly <sboss@meta.com>
architecture only.
Apple configures CMake only once for compiler-rt, even when building for
multiple architectures. As a result, we need to explicitly test for
arm64 specific attributes by building for that architecture
This PR fixes the bug reported in #134358.
In the current implementation of the tsan posix interceptors, the signal
set does not get restored to the correct original set, if a signal
handler gets called, while already inside of a signal handler. This
leads to the wrong signal set being set for the thread in which the
signal handler was called.
To fix this I introduced a stack of `__sanitizer_sigset_t` to keep all
the correct old signal sets and restore them in the correct order.
There was also already an existing test that tested nested / recursive
signal handlers, but it was disabled.
I therefore reenabled it, made it more robust by waiting for the second
thread to have been properly started and added checks for the signal
sets.
This test then failed before the introduction of the interceptor fix and
didn't fail with the fix.
@dvyukov What are your thoughts?
While investigating an issue with code coverage reporting around
exceptions it was useful to have a baseline of what works today.
This change adds end-to-end testing to validate code coverage behavior
that is currently working with regards to exception handling.
The current region mapping for do-while loops that contain statements
such as break or continue results in inaccurate line coverage reports
for the line following the loop.
This change handles terminating statements the same way that other loop
constructs do, correcting the region mapping for accurate reports. It
also fixes a fragile test relying on exact line numbers.
Fixes#139122
Currently, `Posix/sanitizer_set_report_path_test.cpp` contains the
following check: `// CHECK: ERROR: Can't create directory:
{{.*}}Posix/Output/sanitizer_set_report_path_test.cpp.tmp`. This makes
an assumption that the test file resides in `Posix/Output`, however when
testing on a remote device, an alternative temporary directory path is
used. This patch instead checks that the path in the error message
matches the requested path dynamically.
Many targets have already migrated to the per-target runtime directory
layout, which is generally preferred. For AIX however, we are currently
using per-target runtime directories by default for some runtimes (i.e.
`flang-rt`) but not others. This change makes things consistent for
other runtimes (most primarily `compiler-rt`) as well, adopting the
layout uniformly for the AIX target.
This change also normalizes the triple used for building compiler-rt to
remove any OS version number, as there is currently no need to version
the runtimes this way and the driver code doesn't expect this anyhow.
On ARM64EC, function names and calls (but not address-taking or data
symbol references) use symbols prefixed with "#". Since it's an unique
behavior, introduce a new `FUNC_SYMBOL` macro instead of reusing
something like `SYMBOL_NAME`, which is also used for data symbols.
Based on patch by Billy Laws.
This patch introduces a new optional CMake flag:
COMPILER_RT_EXCLUDE_LIBC_PROVIDED_ARM_AEABI_BUILTINS
When enabled, this flag excludes the following ARM AEABI memory function
implementations from the compiler-rt build:
__aeabi_memcmp
__aeabi_memset
__aeabi_memcpy
__aeabi_memmove
These functions are already provided by standard C libraries like glibc,
newlib, and picolibc, so excluding them avoids duplicate symbol
definitions and reduces unnecessary code duplication.
Note:
- libgcc does not define the __aeabi_* functions that overlap with those
provided by the C library. Enabling this option makes compiler-rt behave
consistently with libgcc.
- This prevents duplicate symbol errors when linking, particularly in
bare-metal configurations where compiler-rt is linked first.
- This flag is OFF by default, meaning all AEABI memory builtins will
still be built unless explicitly excluded.
This change is useful for environments where libc provides runtime
routines, supporting more minimal, conflict free builds.
Sanitizers using this hook on Fuchsia can define this function to do any
extra stuff at the end of the startup hook. For now this is only used by
HWASan which needs to explicitly be initialized before libc extensions
are intitialized.
On 64-bit platforms, libgcc doesn't ship with __clzsi2, so __builtin_clz
gets lowered to __clzdi2. A check already exists for GCC, but as of
commit 8210ca0198 clang also lowers
__builtin_clz to __clzdi2 on sparc64.
Update the check so that building __clzdi2 with clang/sparc64 also
works.
10s looks not enough. With highly parallel test
execution on VMs it's very possible that Asan
report will have no enough time to produce output.
I can reproduce locally 1s is not always enough,
but likely my workstation is faster then buildbot.
Additionally, don't use puts/CHECK to validate
timeout. We can exit with 0 and it should violate
"not" expectation.
Follow up to #131756.
'list.size()' is determined at runtime, so using static_assert on it as
suggested by the TODO comment is not feasible and produces the following
error when done:
error: static assertion expression is not an integral constant
expression
initially referenced in https://github.com/bitcoin/bitcoin/pull/32024
Co-authored-by: Chand-ra <chandrapratap376@gmail.com>
