In powerpc64-unknown-linux-musl, signal.h does not include asm/ptrace.h,
which causes "member access into incomplete type 'struct pt_regs'"
errors. Include the header explicitly to fix this.
Also in sanitizer_linux_libcdep.cpp, there is a usage of TlsPreTcbSize
which is not defined in such a platform. Guard the branch with macro.
At some point FreeBSD introduced libsys as a wrapper between syscalls
and libc, and then linking sanitized programs started failing with:
```text
# c++ -fsanitize=address main.cc
ld: error: undefined symbol: __elf_aux_vector
>>> referenced by sanitizer_linux_libcdep.cpp:950 (/usr/src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp:950)
>>> sanitizer_linux_libcdep.o:(__sanitizer::ReExec()) in archive /usr/lib/clang/17/lib/freebsd/libclang_rt.asan-x86_64.a
c++: error: linker command failed with exit code 1 (use -v to see invocation)
```
Mark `__elf_aux_vector` as weak in the internal sanitizer declaration,
so the linker will accept it at link time. The dynamic linker will then
take care of the symbol at run time.
This should fix SANITIZER_FREEBSD and simplify
SANITIZER_GLIBC version.
Also the PR make readers aware of problematic
`ThreadDescriptorSizeFallback` for SANITIZER_FREEBSD.
Maybe it will encourage FreeBSD maintainers to
improve the functions, or prove that it's not needed at
all.
Since 2c69a09bee94acca859a1adf5b04d01dc13f7295, the Solaris build is
broken like
```
Undefined first referenced
symbol in file
_ZN11__sanitizer20ThreadDescriptorSizeEv projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonLibc.i386.dir/sanitizer_linux_libcdep.cpp.o
```
The `ThreadDescriptorSize` reference is from
`sanitizer_linux_libcdep.cpp` (`GetTls`), l.590. This isn't actually
needed on non-glibc targets AFAICS, so this patch provides a dummy to
restore the build.
Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and
`x86_64-pc-linux-gnu`.
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.)
`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`.
On some systems (e.g., at least two AArch64 Linux instances), the
process map can have:
```
fffffffdf000-1000000000000 ... [stack]
```
instead of:
```
fffffffdf000- ffffffffffff
```
The stack top value is larger than `GetMaxUserVirtualAddress()`, which
violates the precondition that shadow memory calculations expect. This
patch fixes the issue by saturating off-by-one values (and also adds
checks for more flagrant violations).
This fixes an issue that was observed with DFSan on AArch64 Linux (with
high-entropy ASLR, resulting in ASLR being disabled on some runs):
```
==11057==ERROR: DataflowSanitizer failed to allocate 0x1600000800000 (387028101365760) bytes at address 4fffff800000 (errno: 12)
```
(https://lab.llvm.org/staging/#/builders/90/builds/552/steps/9/logs/stdio)
This was trying to allocate a shadow at `[0x4fffff800000, 0x4fffff800000
+ 0x1600000800000] = [0x4fffff800000, 0x1b00000000000]`. Notice that the
end of the shadow region - an invalid value - is equal to
`MEM_TO_SHADOW(0x1000000000000)`, where `MEM_TO_SHADOW` is defined as
`(mem ^ 0xB00000000000ULL)`.
This function is called during very early startup and which can result
in a crash on FreeBSD. The sigaction() function in libc is indirected
via a table so that it can be interposed by the threading library
rather than calling the syscall directly. In the crash I was observing
this table had not yet been relocated, so we ended up jumping to an
invalid address. To avoid this problem we can call __sys_sigaction,
which calls the syscall directly and in FreeBSD 15 is part of libsys
rather than libc, so does not depend on libc being fully initialized.
In the FreeBSD base system, re-executing the main binary when ASLR is
detected was implemented in the following commits:
* freebsd/freebsd-src@7cafe89f9c
* freebsd/freebsd-src@96fe7c8ab0
* freebsd/freebsd-src@930a7c2ac6
* freebsd/freebsd-src@0a736f0a6a
* freebsd/freebsd-src@4c9a0adad1
Squash all these to bring them into upstream compiler-rt.
When ASLR is detected to be enabled, this first force-disables ASLR for
the current process, then calls ReExec(). The ReExec() function gets a
FreeBSD specific implementation for finding the path of the executed
program, via the ELF auxiliary vector. This is done without calling into
the regular elf_aux_info(3) function, as that makes use of several
already-intercepted functions.
An #elif SANITIZER_SOLARIS clause was removed in D120048, but it also
removed the #else clause for the error fallback, causing the build to
fail on NetBSD.
Differential Revision: https://reviews.llvm.org/D146316
- GCC does not recognize $fcsr0, uses $r0 instead.
- GCC does not implement __builtin_thread_pointer, which can be
obtained directly through $tp.
Reviewed By: SixWeining
Differential Revision: https://reviews.llvm.org/D140545
This patch enabled tsan for loongarch64 with 47-bit VMA layout. All
tests are passing.
Also adds assembly routines to enable setjmp/longjmp for loongarch64
on linux.
Reviewed By: dvyukov, SixWeining, #sanitizers
Differential Revision: https://reviews.llvm.org/D138489
This patch, on top of D120048 <https://reviews.llvm.org/D120048>, supports
GetTls on Solaris 11.3 and Illumos that lack `dlpi_tls_modid`. It's the
same method originally used in D91605 <https://reviews.llvm.org/D91605>,
but integrated into `GetStaticTlsBoundary`.
Tested on `amd64-pc-solaris2.11`, `sparcv9-sun-solaris2.11`, and
`x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D120059
On a mips64el-linux-gnu system, the dynamic linker arranges TLS blocks
like:
[0] 0xfff7fe9680..0xfff7fe9684, align = 0x4
[1] 0xfff7fe9688..0xfff7fe96a8, align = 0x8
[2] 0xfff7fe96c0..0xfff7fe9e60, align = 0x40
[3] 0xfff7fe9e60..0xfff7fe9ef8, align = 0x8
Note that the dynamic linker can only put [1] at 0xfff7fe9688, not
0xfff7fe9684 or it will be misaligned. But we were comparing the
distance between two blocks with the alignment of the previous range,
causing GetStaticTlsBoundary fail to merge the consecutive blocks.
Compare against the alignment of the latter range to fix the issue.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D129112
Usually when we generated stacktraces the process is in error state, so
running hooks may crash the process and prevent meaningfull error report.
Symbolizer, unwinder and pthread are potential source of mallocs.
https://b.corp.google.com/issues/228110771
Reviewed By: kda
Differential Revision: https://reviews.llvm.org/D123566
Usually when we generated stacktraces the process is in error state, so
running hooks may crash the process and prevent meaningfull error report.
Symbolizer, unwinder and pthread are potential source of mallocs.
https://b.corp.google.com/issues/228110771
Reviewed By: kda
Differential Revision: https://reviews.llvm.org/D123566
