With the help of @lhames, This pull request introduces the dlupdate
function in the ORC runtime. dlupdate enables incremental execution of
new initializers introduced in the REPL environment. Unlike traditional
dlopen, which manages initializers, code mapping, and library reference
counts, dlupdate focuses exclusively on running new initializers.
In C++ it's UB to use undeclared values as enum.
And there is support __ATOMIC_HLE_ACQUIRE and
__ATOMIC_HLE_RELEASE need such values.
So use `int` in TSAN interface, and mask out
irrelevant bits and cast to enum ASAP.
`ThreadSanitizer.cpp` already declare morder parameterd
in these functions as `i32`.
This may looks like a slight change, as we
previously didn't mask out additional bits for `fmo`,
and `NoTsanAtomic` call. But from implementation
it's clear that they are expecting exact enum.
Reverts llvm/llvm-project#115032
Reapply llvm/llvm-project#114724
In C++ it's UB to use undeclared values as enum.
And there is support `__ATOMIC_HLE_ACQUIRE` and
`__ATOMIC_HLE_RELEASE` need such values.
Internal implementation was switched to `class enum`,
where that behavior is defined. But interface is C, so
we just switch to `int`.
There may not always be available virtual memory at higher addresses
than the target function. Therefore, search also lower addresses while
ensuring that we stay within the accessible memory range.
Additionally, add more ReportError calls to make the reasons for
interception failure more clear.
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
# Why do we think these are unsafe?
mmap and munmap are used for mapping a specific manipulation of the
virtual memory of a process. Typically used in things like databases and
area allocators.
They call the system calls `mmap` and `munmap` under the hood (confirmed
on mac using dtrace)
shm_open/unlink interact with shared memory across processes.
Similarly under the hood, they call the `shm_open`/`shm_unlink` system
calls (confirmed on mac using dtrace)
The runtimes used to support a build mode called the "Standalone build",
which isn't supported anymore (and hasn't been for a few years).
However, various places in the code still contained stuff whose only
purpose was to support that build mode, and some outdated documentation.
This patch cleans that up (although I probably missed some).
- Remove HandleOutOfTreeLLVM.cmake which isn't referenced anymore
- Remove the LLVM_PATH CMake variable which isn't used anymore
- Update some outdated documentation referencing standalone builds
With PR #107223 and PR #107403, ASan testing can be enabled on SPARC.
This patch does so, 32-bit only on both Solaris and Linux. There is no
64-bit support even in GCC.
Apart from the obvious CMake changes, this patch includes a couple of
testcase adjustments necessary for SPARC:
- In `asan_oob_test.cpp`, the `OOB_int` subtest needs to be disabled: it
performs unaligned accesses that cannot work on a strict-alignment
target like SPARC.
- `asan_test.cpp` needs to disable subtests that depend on support for
`__builtin_setjmp` and `__builtin_longjmp`.
- `zero_page_pc.cpp` reports `0x5` as the faulting address on access to
`0x4`. I don't really know why, but it's consistent between Solaris and
Linux.
Tested on `sparcv9-sun-solaris2.11` and `sparc64-unknown-linux-gnu`.
SPARC ABI doesn't use stack realignment, so let LLVM know about it in
`SparcFrameLowering`. This has the side effect of making all overaligned
allocations go through `LowerDYNAMIC_STACKALLOC`, so implement the
missing logic there too for overaligned allocations.
This makes the SPARC backend not crash on overaligned `alloca`s and fix
https://github.com/llvm/llvm-project/issues/89569.
_SC_OPEN_MAX is quite high on FreeBSD, which makes this close() loop a
quite obvious problem when attempting to do any kind of debugging in a
process that uses StartSubprocess. Switch to using close_range(2)
instead to close them all in a single syscall and dramatically reduce
the runtime and syscall trace noise
Linux has an equivalent syscall, but I do not have the capacity to test
that it works there, so this is limited to SANITIZER_FREEBSD for the
time being.
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
---------
Co-authored-by: Vitaly Buka <vitalybuka@gmail.com>
This commit reverts commit 7c55426 (relands commit 97fb21ac)
With the additional step of ignoring a warning that we don't care about. (-Wunguarded-availability-new)
> We know that aligned_alloc will never be called on systems that do not have aligned_alloc defined because the client OSX won't provide it. This function is actually guarded on OS's lower than 10.15 because aligned_alloc declaration won't exist on that version. There will be no way to call this function from code.
Removes sve-bf16, sve-ebf16, and sve-i8mm since they are obsolete. One
could write target_version("sve+bf16") instead of sve-bf16 for instance.
Approved in ACLE as https://github.com/ARM-software/acle/pull/353
The x86_64_lam_qemu buildbots started failing
(https://lab.llvm.org/buildbot/#/builders/139/builds/5462/steps/2/logs/stdio).
Based on the logs, it appears the HWASan check is correct but it did not
match the stderr/stdout output. This patch attempts to fix the issue by
flushing stderr/stdout as appropriate.
Compiling with `-fxray-shared` requires position-independent code
(introduced in #113548).
Some tests do not explicitly specify this, thus falling back to the
compiler default.
If, for example, Clang is compiled with
`-DCLANG_DEFAULT_PIE_ON_LINUX=OFF`, these checks fail.
This patch addresses this issue in two tests:
- Removing a check in `xray-shared.cpp` that only tests default PIC
behavior
- Adding `-fPIC` explicitly in `clang-xray-shared.cpp`
\d, \( and \) are not valid escape sequences; since python 3.12
they give SyntaxWarning, and will raise SyntaxError in future.
https://docs.python.org/3.12/whatsnew/3.12.html#other-language-changes
r"\(\d\)" and "\\(\\d\\)" are equivalent but the former is the shorter.
Co-authored-by: Eisuke Kawashima <e-kwsm@users.noreply.github.com>
This reverts commit 97fb21ac1d6bc528b61a555356457ff2129dfde1.
Due to issue brought up in #112780
> Unfortunately this breaks the build on our (automerger) bots, which
have -mmacosx-version-min=10.13 and also
-Werror=unguarded-availability-new . I was thinking about patching it
via wrapping in __builtin_available check (which I believe is the right
one to use, as it should match the -mmacosx-version-min ) - but can't
actually think of a quick fix, due to interceptors being defined via C
macros.
>
llvm-project/compiler-rt/lib/rtsan/rtsan_interceptors_posix.cpp:475:21:
error: 'aligned_alloc' is only available on macOS 10.15 or newer
[-Werror,-Wunguarded-availability-new] 475 | INTERCEPTOR(void *,
aligned_alloc, SIZE_T alignment, SIZE_T size) {
Include `cstdlib` which was originally included transitively but the
changes to `vector` in libcpp breaks new builds due to missing cstdlib
header for `abort()` function call.
Add explicit symbol visibility macros to InstrProfData.inc
Annotating these symbols will fix missing symbols for InstrProfTest when
using shared library builds on windows with explicit visibility macros
enabled.
Add a empty fallback definition for LLVM_ABI macro so the code works in
compiler-rt.
This is part of the work to enable LLVM_BUILD_LLVM_DYLIB and plugins on
window.
```
llvm\lld-link : error : undefined symbol: public: void ValueProfData::deserializeTo(InstrProfRecord&, InstrProfSymtab*)
>>> referenced by unittests\ProfileData\InstrProfTest.cpp:1372 void ValueProfileReadWriteTest_value_prof_data_read_write_Test::TestBody()
```
# What
This PR renames the newly-introduced llvm attribute
`sanitize_realtime_unsafe` to `sanitize_realtime_blocking`. Likewise,
sibling variables such as `SanitizeRealtimeUnsafe` are renamed to
`SanitizeRealtimeBlocking` respectively. There are no other functional
changes.
# Why?
- There are a number of problems that can cause a function to be
real-time "unsafe",
- we wish to communicate what problems rtsan detects and *why* they're
unsafe, and
- a generic "unsafe" attribute is, in our opinion, too broad a net -
which may lead to future implementations that need extra contextual
information passed through them in order to communicate meaningful
reasons to users.
- We want to avoid this situation and make the runtime library boundary
API/ABI as simple as possible, and
- we believe that restricting the scope of attributes to names like
`sanitize_realtime_blocking` is an effective means of doing so.
We also feel that the symmetry between `[[clang::blocking]]` and
`sanitize_realtime_blocking` is easier to follow as a developer.
# Concerns
- I'm aware that the LLVM attribute `sanitize_realtime_unsafe` has been
part of the tree for a few weeks now (introduced here:
https://github.com/llvm/llvm-project/pull/106754). Given that it hasn't
been released in version 20 yet, am I correct in considering this to not
be a breaking change?
This fixes remaining issues in my previous PR #90959.
Changes:
- Removed dependency on LLVM header in `xray_interface.cpp`
- Fixed XRay patching for some targets due to missing changes in
architecture-specific patching functions
- Addressed some remaining compiler warnings that I missed in the
previous patch
- Formatting
I have tested these changes on `x86_64` (natively), as well as
`ppc64le`, `aarch64` and `arm32` (cross-compiled and emulated using
qemu).
**Original description:**
This PR introduces shared library (DSO) support for XRay based on a
revised version of the implementation outlined in [this
RFC](https://discourse.llvm.org/t/rfc-upstreaming-dso-instrumentation-support-for-xray/73000).
The feature enables the patching and handling of events from DSOs,
supporting both libraries linked at startup or explicitly loaded, e.g.
via `dlopen`.
This patch adds the following:
- The `-fxray-shared` flag to enable the feature (turned off by default)
- A small runtime library that is linked into every instrumented DSO,
providing position-independent trampolines and code to register with the
main XRay runtime
- Changes to the XRay runtime to support management and patching of
multiple objects
These changes are fully backward compatible, i.e. running without
instrumented DSOs will produce identical traces (in terms of recorded
function IDs) to the previous implementation.
Due to my limited ability to test on other architectures, this feature
is only implemented and tested with x86_64. Extending support to other
architectures is fairly straightforward, requiring only a
position-independent implementation of the architecture-specific
trampoline implementation (see
`compiler-rt/lib/xray/xray_trampoline_x86_64.S` for reference).
This patch does not include any functionality to resolve function IDs
from DSOs for the provided logging/tracing modes. These modes still work
and will record calls from DSOs, but symbol resolution for these
functions in not available. Getting this to work properly requires
recording information about the loaded DSOs and should IMO be discussed
in a separate RFC, as there are mulitple feasible approaches.
---------
Co-authored-by: Sebastian Kreutzer <sebastian.kreutzer@tu-darmstadt.de>
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 \
-DLLVM_BINARY_DIR=/tmp/upstream-llvm-readonly \
-G Ninja -S ~/upstream-llvm-project/runtimes \
-B ~/upstream-llvm-project/runtimes/cmake-build-debug-llvm-git
```
Reviewed By: ldionne
Pull Request: https://github.com/llvm/llvm-project/pull/86209
Some platforms (e.g. 64-bit CHERI) have stronger alignment requirements
on values returned from allocators. For all other platforms this does
not result in any functional change.
Reviewed By: cjappl, vitalybuka
Pull Request: https://github.com/llvm/llvm-project/pull/84440
