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.
Since b4130bee6bfd34d8045f02fc9f951bcb5db9d85c, we check for
_LIBCPP_HAS_THREAD_API_PTHREAD to decide between using
SetThreadDescription or pthread_setname_np for setting the thread name.
c6f3b7bcd0596d30f8dabecdfb9e44f9a07b6e4c changed how libcxx defines
their configuration macros - now they are always defined, but defined to
0 or 1, while they previously were either defined or undefined.
As these libcxx defines used to be defined to an empty string (rather
than expanding to 1) if enabled, we can't easily produce an expression
that works both with older and newer libcxx. Additionally, these defines
are libcxx internal config macros that aren't a detail that isn't
supported and isn't meant to be relied upon.
Simply skip trying to set thread name on MinGW as we can't easily know
which kind of thread native handle we have. Setting the thread name is
only a nice to have, quality of life improvement - things should work
the same even without it.
Additionally, libfuzzer isn't generally usable on MinGW targets yet
(Clang doesn't include it in the getSupportedSanitizers() method for the
MinGW target), so this shouldn't make any difference in practice anyway.
Using the build tree is somewhat fragile since the layout is not
guaranteed to be stable and means the tests are tightly coupled to the
libc++/libc++abi build tree layout. Instead update the ExternalProject
to install the library and headers and do not add the build tree to
the include/linker flags.
Pull Request: https://github.com/llvm/llvm-project/pull/115077
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
