Using a `--section-start` address in the test was causing link errors on
some targets. Now it uses a linker script to move the note after `.bss`,
which should still have the kind of memory offset we're looking for.
This is a follow-up to #114907 to fix buildbot errors.
This relands #86209 which was reverted because ./bin/llvm no longer
accepted test paths in the source tree instead of the build tree. This was
happening because `add_subdirectory(${LLVM_MAIN_SRC_DIR}/utils/llvm-lit`
was called before all tsst suites were registered, and therefore it was
missing the source->build dir mappings.
Original commit message:
I am currently trying to test the LLVM runtimes (including compiler-rt)
against an installed LLVM tree rather than a build tree (since that is
no longer available). Currently, the runtimes build of compiler-rt assumes
that LLVM_BINARY_DIR is writable since it uses configure_file() to write
there during the CMake configure stage. Instead, generate this file inside
CMAKE_CURRENT_BINARY_DIR, which will match LLVM_BINARY_DIR when invoked
from llvm/runtimes/CMakeLists.txt.
I also needed to make a minor change to the hwasan tests: hwasan_symbolize
was previously found in the LLVM_BINARY_DIR, but since it is generated as
part of the compiler-rt build it is now inside the CMake build directory
instead. I fixed this by passing the output directory to lit as
config.compiler_rt_bindir and using llvm_config.add_tool_substitutions().
For testing that we no longer write to the LLVM install directory as
part of testing or configuration, I created a read-only bind mount and
configured the runtimes builds as follows:
```
$ sudo mount --bind --read-only ~/llvm-install /tmp/upstream-llvm-readonly
$ cmake -DCMAKE_BUILD_TYPE=Debug \
-DCMAKE_C_COMPILER=/tmp/upstream-llvm-readonly/bin/clang \
-DCMAKE_CXX_COMPILER=/tmp/upstream-llvm-readonly/bin/clang++ \
-DLLVM_INCLUDE_TESTS=TRUE -DLLVM_ENABLE_ASSERTIONS=TRUE \
-DCOMPILER_RT_INCLUDE_TESTS=TRUE -DCOMPILER_RT_DEBUG=OFF \
-DLLVM_ENABLE_RUNTIMES=compiler-rt \
-DCMAKE_DISABLE_FIND_PACKAGE_LLVM=TRUE \
-DCMAKE_DISABLE_FIND_PACKAGE_Clang=TRUE \
-G Ninja -S ~/upstream-llvm-project/runtimes \
-B ~/upstream-llvm-project/runtimes/cmake-build-debug-llvm-git
```
Pull Request: https://github.com/llvm/llvm-project/pull/114307
I've run into an issue where TSan can't be used on some code without
turning off deadlock detection because a thread tries to hold too many
mutexes. It would be preferable to be able to use deadlock detection as
that is a major benefit of TSan.
Its mentioned in https://github.com/google/sanitizers/issues/950 that
the 64 mutex limit was an arbitrary number. I've increased it to 128 and
all the tests still pass. Considering the increasing number of cores on
CPUs and how programs can now use more threads to take advantage of it,
I think raising the limit to 128 would be some good future proofing
---------
Co-authored-by: Vitaly Buka <vitalybuka@google.com>
This function is always examining its own ELF headers in memory, but it
was trying to use conditions between examining files or memory, and it
wasn't accounting for LOAD offsets at runtime. This is especially bad if
a loaded segment has additional padding that's not in the file offsets.
Now we do a first scan of the program headers to figure out the runtime
base address based on `PT_PHDR` and/or `PT_DYNAMIC` (else assume zero),
similar to libc's `do_start`. Then each `PT_NOTE` pointer is simply the
base plus the segments's `pt_vaddr`, which includes LOAD offsets.
Fixes#114605
Following the example of tsan, where we took the name
This would allow users to determine if they want to see ALL output from
rtsan.
Additionally, remove the UNLIKELY hint, as it is now up to the flag whether or
not it is likely that we go through this conditional.
This calls the system calls switch_pri and sys_ulock_wait. It also is
one of the more straightforwardly rt-unsafe, in that it gives up this
thread's timeslice.
This tests that a simple C++ static initializer works as expected.
Compared to the architecture specific, assembly level regression tests for the
ORC runtime; this test is expected to catch cases where the compiler adopts
some new MachO feature that the ORC runtime does not yet support (e.g. a new
initializer section).
## Why we think this are unsafe
Again, these correspond directly to system calls on linux and OSX. They
are two ways to do interprocess communication so it would make sense
that they take some synchronization by the OS.
Certain tests (many are from lld/test) run `... '2>&1 | count 0` to
ensure that there is no stderr message.
GetRegistersAndSP may rarely fail, leading to
a spurious failure like (with a local hack to make `count` dump the
input):
```
+ /home/ray/llvm/out/asan/bin/ld.lld func1-gcs.o func2-gcs.o func3-gcs.o -o /dev/null -z gcs-report=warning -z gcs=never
+ /home/ray/llvm/out/asan/bin/count 0
Expected 0 lines, got 1.
==2403039==Unable to get registers from thread 2403018.
```
The failure can reliably be reproduced by running `ninja check-lld` a
few times under asan+lsan (see the bot
sanitizer-x86_64-linux-bootstrap-asan).
# Why we think these are real-time unsafe
They correspond directly to system calls in linux and OSX, they are
manipulating a shared resource, which likely takes some operating-system
synchronization.
Adding support for the extra SUMMARY line that is output by most
compilers. This also adds the ability for end-users to specify their own
handlers for reporting these errors (see the test).
Original commit 2ec5c69b6872b8b474f3d37b9125d3d57d144d1b only
intercepted timer_create.
Because of how versioned libc symbols work, this could cause problems
where a newer `timer_create`
was used, and the result would be used by an older version. This would
cause crashes. This is why we
need to intercept all of the related functions.
Addresses https://github.com/llvm/llvm-project/issues/111847
Intercepts in the family of `poll`, `select` and modern equivalents
`epoll` (linux only) and `kqueue` bsd family only.
These calls mirror the names of the system calls they call, which have
been verified on mac at least (e.g. kevent calls the system call
kevent).
The original patch (25fd366d6a7d40266ff27c134ed8beb0a90cc33b) was
reverted in 083a5cdbeab09517d8345868970d4f41170d7ed2 because it broke
some buildbots.
This revised patch makes two changes:
- Reverts to *pre-#98200* behavior for Android. This avoids a build
breakage on Android.
- Only define KeepUnblocked if SANITIZER_LINUX: this avoids a build
breakage on solaris, which does not support internal_sigdelset.
N.B. Other buildbot failures were non-sanitizer tests and are therefore
unrelated.
Original commit message:
My earlier patch https://github.com/llvm/llvm-project/pull/98200
caused a regression because it unconditionally unblocked synchronous
signals, even if the user program had deliberately blocked them.
This patch fixes the issue by checking the current signal mask, as
suggested by Vitaly. It also adds tests.
Fixes#113385
The INSTALL_BYPRODUCTS ExternalProject_Add() argument was only added in
CMake 3.26 and the current minimum is 3.20. Work around this by using an
explicit ExternalProject_Add_Step() call for the install step with a
BYPRODUCTS argument. We can't keep using the `install` name here since that
is reserved by the CMake implementation and results in errors when used.
This commit should be reverted once LLVM depends on CMake 3.26.
Pull Request: https://github.com/llvm/llvm-project/pull/115677
This patch implements support for `-fxray-shared` on AArch64 and fixes a
remaining issue in the previous PR #114431.
A bug in the XRay `CMakeLists.txt` caused the XRay assembly sources to
be built for every architecture in `XRAY_DSO_SUPPORTED_ARCH` on Apple.
This led to the compiler trying to compile AArch64 assembly for X86
targets and vice versa.
This is addressed here by ensuring that assembly sources are only built
for the matching architecture (see fixup commit).
**Original PR description:**
This patch adds support for `-fxray-shared` on AArch64. This feature,
introduced in #113548 for x86_64, enables the instrumentation of shared
libraries with XRay.
Changes:
- Adds AArch64 to the list of targets supporting `-fxray-shared`
- Introduces PIC versions of the AArch64 XRay trampolines
- Adjusts relevant XRay tests
Features ebf16, memtag3, and rpres allow existing instructions to behave
differently depending on the value of certain control registers. FMV
does not read the content of control registers making these features
unsuitable for runtime dispatch. See the ACLE patch for more info:
https://github.com/ARM-software/acle/pull/355
These two libraries don't build for `-march=armv8-a+nofp
-mabi=aapcs-soft` as a couple of uses of floating point instructions and
registers have crept in.
In libunwind, skip save/restore of FPU registers on targets without them.
In compiler-rt, fall back to the old C implementation of __arm_sc_memset when
the target doesn't have an FPU.
---------
Signed-off-by: Keith Packard <keithp@keithp.com>
…t constructor
`__init_riscv_feature_bits` takes an argument that can be
platform-specific, potentially pointing to the VDSO address of the
hwprobe system call for Linux. However, marking it as a constructor does
not guarantee that 0/NULL will always be passed to this argument, which
may result in treating an uninitialized or garbage value as a pointer to
hwprobe, leading to a crash.
The simplest solution is to introduce a small constructor function to
ensure that the platform-specific argument is set to 0/NULL.
