When ASan testing is enabled on SPARC as per PR #107405, the
```
AddressSanitizer-sparc-linux :: TestCases/Linux/odr_c_test.c
```
test `FAIL`s on Linux/sparc64:
```
+ projects/compiler-rt/test/asan/SPARCLinuxConfig/TestCases/Linux/Output/odr_c_test.c.tmp
+ count 0
Expected 0 lines, got 13.
AddressSanitizer:DEADLYSIGNAL
=================================================================
==4165420==ERROR: AddressSanitizer: BUS on unknown address (pc 0x7012d5b4 bp 0xffa3b938 sp 0xffa3b8d0 T0)
==4165420==The signal is caused by a READ memory access.
==4165420==Hint: this fault was caused by a dereference of a high value address (see register values below). Disassemble the provided pc to learn which register was used.
```
The test relies on an unaligned access, which cannot work on a
strict-alignment target like SPARC.
Thus this patch skips the test.
Tested on `sparc64-unknown-linux-gnu`.
This fixes#108936, but the calling convention doesn't match with GCC. I
doubt we have such a lib function for now, so leave the calling
convention as is.
Later in a development branch, our c tests were failing, this was due to
the lack of RTTI.
This follows very similar patterns found in the other sanitizers
Since we may copy code (see CopyInstructions) to the trampoline which
could reference data inside the original module, we really want the
trampoline to be within 2 GB of not just the original function, but
within anything that function may have rip-relative accesses to, i.e.
within 2 GB of that function's whole module.
This fixes interception failures like the following scenario:
1. Intercept `CreateProcess` in kernel32.dll, allocating a trampoline
region right after
2. Start intercepting `memcpy` in the main executable, which is loaded
at a lower address than kernel32.dll, but still within 2 GB of the
trampoline region so we keep using it.
3. Try to copy instructions from `memcpy` to the trampoline. Turns out
one instruction references data that is more than 2GB away from the
trampoline, so it can't be relocated.
4. The process exits due to a CHECK failure
(Full story at https://crbug.com/341936875#comment45 and following.)
The check is too strict. It works for 2.38 I have,
but not for older glibc which used different
allocation code.
The check was introduced with #108345.
`DlSymAllocator` allows early allocations, when
tsan is not yet initialized, e.g. from `dlsym`.
All other sanitizers with interceptors already use
`DlSymAllocator`.
Existing `in_symbolizer()` tsan logic is very similar.
However, we need to keep both as `DlSymAllocator`
does not support large allocations, needed for Symolizer.
I grep the code and find that `Abort()` is only called in `Die()` when
the flag `abort_on_error` is set.
Thus, if reserving shadow memory range fails, `Die()` rather than
`Abort()` should be called. In this case, the flag `abort_on_error` will
be respected and the die callbacks will be called.
Fixes asan, msan crash on check added in #108684.
The #108684 includes reproducer of the issue.
Change interface of `GetThreadStackAndTls` to
set `tls_begin` and `tls_end` at the same time.
This reverts commit 69f3244da76586be393d1e97b01660c6f03d666c.
Reason: buildbot breakage because Android doesn't have <gnu/libc-version.h>
https://lab.llvm.org/buildbot/#/builders/186/builds/2381
(It's probably easy to fix but I don't readily have an Android device to test.)
Secondary cache entries are now released to the OS from least recent to
most recent entries. This helps to avoid unnecessary scans of the cache
since entries ready to be released (specifically, entries that are
considered old relative to the configurable release interval) will
always be at the tail of the list of committed entries by the LRU
ordering. For this same reason, the `OldestTime` variable is no longer
needed to indicate when releases are necessary so it has been removed.
There is possibility of
static_tls_begin is set and static_tls_end is not yet
The test reproduces the case.
Stack trace looks like this:
* `MsanThread::Init`
* `SetThreadStackAndTls`
* `GetThreadStackAndTls`
* `GetThreadStackTopAndBottom`
* `pthread_getattr_np`
* `realloc`
* `__sanitizer_malloc_hook`
* TLS access
* `___interceptor___tls_get_addr`
* `DTLS_on_tls_get_addr`
The issue is that `SetThreadStackAndTls` implementation
stores `tls_begin` before `GetThreadStackTopAndBottom`,
and `tls_end` after. So we have partially initialized
state in `DTLS_on_tls_get_addr`.
`gnu_get_libc_version` unlike `confstr` is not
intercepted. We should be able to use this
function earier.
Looks like we use `confstr` staring from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60038
but there is no specific reason to refer it over
`gnu_get_libc_version`.
Allows unloading and reloading of ignored libraries. We don't attempt to
reuse or free memory of unloaded library. So TSan will assert if an
ignored library is reloaded 128 times.
Co-authored-by: Vitaly Buka <vitalybuka@gmail.com>
When enabling ASan testing on SPARC as per PR #107405, two tests `FAIL`
in similar ways as detailed in Issue #108194: at `-O1` and above, one
line of the stacktrace lacks the line number info, causing the tests to
`FAIL`. I could trace this to `clang` generating incomplete line number
info; `g++` gets this right.
To avoid this, this patch `XFAIL`s the affected tests on SPARC.
Tested on `sparcv9-sun-solaris2.11`.
…p etc. on SPARC
When enabling ASan testing on SPARC as per PR #107405, two tests `FAIL`:
```
SanitizerCommon-asan-sparc-SunOS :: sanitizer_coverage_trace_pc_guard-dso.cpp
SanitizerCommon-asan-sparc-SunOS :: sanitizer_coverage_trace_pc_guard.cpp
```
The issue is the same in both cases:
```
WARNING: No coverage file for projects/compiler-rt/test/sanitizer_common/asan-sparc-SunOS/Output/sanitizer_coverage_trace_pc_guard.cpp.tmp
WARNING: No coverage file for sanitizer_coverage_trace_pc_guard.cpp.tmp.22766.sancov
ERROR: No valid coverage files given.
```
Checking the file with `sancov -print` reveals `Wrong magic:
4294967090`. There seems to be an endianess bug somewhere, since the
tests are already disabled on other big-endian targets.
This patch matches this.
Tested on `sparcv9-sun-solaris2.11`.
When SPARC Asan testing is enabled by PR #107405, many Linux/sparc64
tests just hang like
```
#0 0xf7ae8e90 in syscall () from /usr/lib32/libc.so.6
#1 0x701065e8 in __sanitizer::FutexWait(__sanitizer::atomic_uint32_t*, unsigned int) ()
at compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp:766
#2 0x70107c90 in Wait ()
at compiler-rt/lib/sanitizer_common/sanitizer_mutex.cpp:35
#3 0x700f7cac in Lock ()
at compiler-rt/lib/asan/../sanitizer_common/sanitizer_mutex.h:196
#4 Lock ()
at compiler-rt/lib/asan/../sanitizer_common/sanitizer_thread_registry.h:98
#5 LockThreads ()
at compiler-rt/lib/asan/asan_thread.cpp:489
#6 0x700e9c8c in __asan::BeforeFork() ()
at compiler-rt/lib/asan/asan_posix.cpp:157
#7 0xf7ac83f4 in ?? () from /usr/lib32/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
```
It turns out that this happens in tests using `internal_fork` (e.g.
invoking `llvm-symbolizer`): unlike most other Linux targets, which use
`clone`, Linux/sparc64 has to use `__fork` instead. While `clone`
doesn't trigger `pthread_atfork` handlers, `__fork` obviously does,
causing the hang.
To avoid this, this patch disables `InstallAtForkHandler` and lets the
ASan tests run to completion.
Tested on `sparc64-unknown-linux-gnu`.
Test for #108348 which is almost NFC. However, the test
may fail on some platforms, and a few iterations could be
needed to filter out unsupported platforms.
