Introduce common infrastructure for runtimes that determines compiler
resource path locations. These variables introduced are:
* RUNTIMES_OUTPUT_RESOURCE_DIR
* RUNTIMES_INSTALL_RESOURCE_PATH
That contain the location for the compiler resource path (typically
`lib/clang/<version>`) in the build tree and the install tree (the
latter relative to CMAKE_INSTALL_PREFIX).
Additionally, define
* RUNTIMES_OUTPUT_RESOURCE_LIB_DIR
* RUNTIMES_INSTALL_RESOURCE_LIB_PATH
as for the location of clang/flang version-locked libraries (typically
`lib${LLVM_LIBDIR_SUFFIX}/<targer-triple>`, but also depends on `APPLE`
and `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR`). This code is moved from
flang-rt and initially becomes its only user.
Refactored out of #171610 as requested
[here](https://github.com/llvm/llvm-project/pull/171610#discussion_r2687382481).
Extracted `get_runtimes_target_libdir_common` from compiler-rt as
requested
[here](https://github.com/llvm/llvm-project/pull/171610#discussion_r2689565634).
Added TODO comments to all runtimes as requested
[here](https://github.com/llvm/llvm-project/pull/171610#issuecomment-3789598635).
Pointer field protection has the following characteristics:
- Pointer fields in RTTI types are unsigned. Signing these fields
is unnecessary because PFP is a mechanism for protecting the heap,
and the RTTI objects typically live in global variables. Therefore,
mark the fields with the no_field_protection to inhibit PFP for these
fields.
- libcxx's interim trivial relocatability implementation, which memcpy's
some non-trivially-copyable objects according to the value of a trait,
conflicts with PFP in tagged mode (in which the address of the pointer
is used as part of the pointer encoding) by causing such copies to
result in a crash in some cases where the object being copied includes
a pointer field. These copies are undefined behavior. Therefore, make
libcxx's trivially relocatable predicate simply return the value of
the trivially copyable trait when PFP in tagged mode is enabled, which
results in standards compliant behavior that is accommodated by PFP.
Reviewers: philnik777, fmayer, ldionne
Pull Request: https://github.com/llvm/llvm-project/pull/151651
This performs most of the post-branch tasks to start working on the LLVM
23 release. Things that are left to do:
- Update the unicode version
- Update CI versions and supported compiler versions
Using `_LIBCPP_WEAK` doesn't give us anything that using `[[gnu::weak]]`
directly couldn't, so we can just expand the macro.
As a drive-by this also refactors `_LIBCPP_OVERRIDABLE_FUNCTION`.
Currently `_LIBCPP_OVERRIDABLE_FUNCTION` takes the return type, function
name and argument list, but simply constructs the function and adds
attributes without modifying the signature in any way. We can replace
this with a normal attribute macro, making the signature easier to read
and simpler to understand what's actually going on. Since it's an
internal macro we can also drop the `_LIBCPP_` prefix.
Introducing the notion of a minimum header version has multiple
benefits. It allows us to merge a bunch of ABI macros into a single one.
This makes configuring the library significantly easier, since, for a
stable ABI, you only need to know which version you started distributing
the library with, instead of checking which ABI flags have been
introduced at what point. For platforms which have a moving window of
the minimum version a program has been compiled against, this also makes
it simple to remove symbols from the dylib when they can't be used by
any program anymore.
This patch removes explicit dependencies on cxx_experimental for
installations that are local to the test suite. Such dependencies
are not required anymore from the test-suite installation targets
since the proper dependency is now encoded between cxx and
cxx_experimental.
Based on comments in #171474, it was brought to my attention that we can
modernize and simplify how we perform the test suite installation in
libc++ and libc++abi.
This patch moves away from using cmake_install scripts to install the
various targets when building runtimes, since those have been deprecated
by CMake. Instead, we use `cmake --install` which is the prefered
method.
This patch also localizes how we set dependencies on the various
installation targets, allowing the removal of a few global variables
that were used as lists.
Finally, it makes the way we set up installation targets for libc++,
libc++abi and libunwind consistent again.
Implementation files using the Intel syntax typically explicitly specify
it. Do the same for the few files where applicable for AT&T.
This enables building LLVM with `-mllvm -x86-asm-syntax=intel` in one's
Clang config files (i.e. a global preference for Intel syntax).
Currently `OutputBuffer::GtIsGt` is used to tell us if we're inside
template arguments and have printed a '(' without a closing ')'. If so,
we don't need to quote '<' when printing it as part of a binary
expression inside a template argument. Otherwise we need to. E.g.,
```
foo<a<(b < c)>> // Quotes around binary expression needed.
```
LLDB's `TrackingOutputBuffer` has heuristics that rely on checking
whether we are inside template arguments, regardless of the current
parentheses depth. We've been using `isGtInsideTemplateArgs` for this,
but that isn't correct. Resulting in us incorrectly tracking the
basename of function like:
```
void func<(foo::Enum)1>()
```
Here `GtIsGt > 0` despite us being inside template arguments (because we
incremented it when seeing '(').
This patch adds a `isInsideTemplateArgs` API which LLDB will use to more
accurately track parts of the demangled name.
To make sure this API doesn't go untested in the actual libcxxabi
test-suite, I changed the existing `GtIsGt` logic to use it. Also
renamed the various variables/APIs involved to make it (in my opinion)
more straightforward to understand what's going on. But happy to rename
it back if people disagree.
Also adjusted LLDB to use the newly introduced API (and added a
unit-test that would previously fail).
In https://github.com/llvm/llvm-project/pull/137947 I refactored the
script and added a `copy_files` function, which takes the header files
to copy as an argument.
But because the list of headers is a space separated string, we need to
quote the string. Otherwise we would just copy the first header in the
list.
This patch also adds an `echo` statement in the `copy_files` loop to
print the source/destination. Confirming that the files are copied as
expected.
```
$ libcxxabi/src/demangle/cp-to-llvm.sh
This will overwrite the copies of ItaniumDemangle.h ItaniumNodes.def StringViewExtras.h Utility.h in ../../../llvm/include/llvm/Demangle and DemangleTestCases.inc in ../../../llvm/include/llvm/Demangle/../Testing/Demangle; are you sure? [y/N]y
Copying ./ItaniumDemangle.h to ../../../llvm/include/llvm/Demangle/ItaniumDemangle.h
Copying ./ItaniumNodes.def to ../../../llvm/include/llvm/Demangle/ItaniumNodes.def
Copying ./StringViewExtras.h to ../../../llvm/include/llvm/Demangle/StringViewExtras.h
Copying ./Utility.h to ../../../llvm/include/llvm/Demangle/Utility.h
Copying ../../test/DemangleTestCases.inc to ../../../llvm/include/llvm/Demangle/../Testing/Demangle/DemangleTestCases.inc
```
Luckily there weren't any out-of-sync changes introduced in the
meantime.
4eed68357e4361b3a3aeb349dec2612cfb74c8cc updated the LLVM side but did
not bump the libc++abi version. Bump the libc++abi version to fix the
test failure caused by the versions differing.
An LLVM 19-aligned libc++ was released with macOS 15.4 (and corresponding OSes),
and LLVM-20 aligned with macOS 26.0. This patch adds availability markup to
reflect that.
This patch reverts e15025dd and 88e15b781 which were temporary measures
until we had figured out the underlying issues. It turns out that recent
OSes updated localization data, removing the need for several Apple-specific
workarounds in the tests.
Fixes#135385
This hardens the unwinding logic and datastructures on systems
that support pointer authentication.
The approach taken to hardening is to harden the schemas of as many
high value fields in the myriad structs as possible, and then also
explicitly qualify local variables referencing privileged or security
critical values.
This does introduce ABI linkage between libcxx, libcxxabi, and
libunwind but those are in principle separate from the OS itself
so we've kept the schema definitions in the library specific headers
rather than ptrauth.h
Based on review feedback in #160026.
This makes the substitution a lot more clear now that there is no
documentation around %T.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
In the libc++ test suite, we consistently declare main() functions with
full parameters and explicitly return from the function. This helps code
that compiles the tests with -ffreestanding, where main() is not a
special function (with an implicit return and special mangling).
This patch fixes a few stray declarations, including in libunwind and
libc++abi.
Our host compiler is a clang install that will default to ld if not told
otherwise.
We were telling meson to use lld, but the way that we did it was
outdated, which lead to picolib producing a linker script that lld could
not use. The tests were in fact linking with ld instead.
Using the `c_ld` setting fixes this problem. See:
https://mesonbuild.com/Machine-files.html#binaries
Then to use lld in tests we need `-fuse-ld=lld` in the config files.
Some of these options were not needed for clang 19.1.7, but were for
clang 21.1.1. We will soon update to 21.1.1 so I have included all of
the required options in this PR.
A CMake change included in CMake 4.0 makes `AIX` into a variable
(similar to `APPLE`, etc.)
ff03db6657
However, `${CMAKE_SYSTEM_NAME}` unfortunately also expands exactly to
`AIX` and `if` auto-expands variable names in CMake. That means you get
a double expansion if you write:
`if (${CMAKE_SYSTEM_NAME} MATCHES "AIX")`
which becomes:
`if (AIX MATCHES "AIX")`
which is as if you wrote:
`if (ON MATCHES "AIX")`
You can prevent this by quoting the expansion of "${CMAKE_SYSTEM_NAME}",
due to policy
[CMP0054](https://cmake.org/cmake/help/latest/policy/CMP0054.html#policy:CMP0054)
which is on by default in 4.0+. Most of the LLVM CMake already does
this, but this PR fixes the remaining cases where we do not.
Assertion semantics closely mimic C++26 Contracts evaluation semantics.
This brings our implementation closer in line with C++26 Library Hardening
(one particular benefit is that using the `observe` semantic makes adopting
hardening easier for projects).
## Purpose
This patch is one in a series of code-mods that annotate LLVM’s public
interface for export. This patch annotates the `Demangle` interface with
a new `DEMANGLE_ABI` annotation, which behaves like the `LLVM_ABI`. This
annotation currently has no meaningful impact on the LLVM build;
however, it is a prerequisite to support an LLVM Windows DLL (shared
library) build.
## Overview
1. Add a new `Demangle/Visibility.h` header file that defines a new
`DEMANGLE_ABI` macro. The macro resolves to the proper DLL export/import
annotation on Windows and a "default" visibility annotation elsewhere.
2. Add a new `LLVM_ENABLE_DEMANGLE_EXPORT_ANNOTATIONS ` `#cmakedefine`
that is used to gate the definition of `DEMANGLE_ABI`.
3. Code-mod annotate the public `Demangle` interface using the
[Interface Definition Scanner (IDS)](https://github.com/compnerd/ids)
tool.
4. Manually fix-up `#include` statements for consistency.
5. Format the changes with `clang-format`.
6. Add a "stub" version of `Visibility.h` under `libcxxabi/src/demangle`
that always defines `DEMANGLE_ABI` to nothing.
7. Update the canonical `libcxxabi/src/demangle/ItaniumDemangle.h`
instead of the llvm copy, and run `cp-to-llvm.sh` to ensure the llvm
copy matches. NOTE: we rely on `ccp-to-llvm.sh` not copying
`Visibillity.h` as is already the case for `DemangleConfig.h`.
## Background
This PR follows the pattern established with the `llvm-c` changes made
in #141701.
This effort is tracked in #109483. Additional context is provided in
[this
discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307),
and documentation for `LLVM_ABI` and related annotations is found in the
LLVM repo
[here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst).
## Validation
Local builds and tests to validate cross-platform compatibility. This
included llvm, clang, and lldb on the following configurations:
- Windows with MSVC
- Windows with Clang
- Linux with GCC
- Linux with Clang
- Darwin with Clang
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Assertion semantics closely mimic C++26 Contracts evaluation semantics.
This brings our implementation closer in line with C++26 Library
Hardening (one particular benefit is that using the `observe` semantic
makes adopting hardening easier for projects).
This makes the logic and code structure match that of libc++, which handles this case (i.e. the target subdirectory being changed).
The `%{target}` substitution from libc++ is removed as libc++abi's config seems to be the only place it's used.
The front-end expects _BitInt to be available for substitution; ensure DB<n> is
added to Subs in ItaniumDemangle.h. Also add a test case to libc++abi and
sync the files to llvm/include/llvm.
Parameterize (and rename) existing libc++/libc++abi test configuration
files for the Android NDK to work for both the NDK and platform.
Android LLVM downstream seeks to test libc++ for both the NDK and
platform build (currently only testing the NDK), which will use almost
identical test configuration files. The only difference is the name of
the libc++ shared object used. Because of this we parameterize the
current test files (for both libc++ and libc++abi) with the existing
LIBCXX_SHARED_OUTPUT_NAME cmake variable, and rename the file
accordingly.
This patch turns the `libcxxabi/test/test_demangle.pass.cpp` into gtest
unit-tests in `llvm/unittests/Demangle`. The main motivation for this is
https://github.com/llvm/llvm-project/pull/137793, where we want to
re-use the test-cases from the ItaniumDemangler to test our OutputBuffer
implementation.
`libcxxabi/test/test_demangle.pass.cpp` now only tests the
`__cxa_demangle` API surface, not the underlying ItaniumDemangle
implementation.
ItaniumDemangle.h exists in both llvm/ and libcxxabi/. These files are
supposed to be copies of each other (minus the top two lines). This
patch adds a test to assert that this is the case to enable tooling to
automatically detect this as an issue, like in #139825. This makes it
easier for contributors unfamiliar with the duplication to make
changes/get appropriate reviews.
Ideally we would share the file and copy it from one place to the other
but the ideal way to do this (based on previous discussion with libc++
maintainers) would be a new runtime library that clearly outlines
requirements, so that is left for later with the test being used as a
stopgap. This is a relatively common approach for structures shared
between compiler-rt and LLVM.
This patch does make the test reference the LLVM source directory, but
that should be fine given building libcxxabi is only supported through
the runtimes build in the monorepo meaning it should always be
available.
76ba29bfd8e8aaf5b0267598d18434a0d13945a2 landed changes in
ItaniumDemangle.h on the LLVM side that were not propagated over to the
libcxxabi side. This patch fixes that.
Some code paths normalize ".." and thus don't create the directory. But some execute in a
shell thus requiring the directory to exist to be able to take the parent directory.
This patch normalizes all the `TARGET_SUBDIR` variables to avoid this issue.
Compilers can generate mangled names such as `_ZN1CpmEi` which we
currently fail to demangle. The OperatorInfo table only marked the `pt`
operator as being "named", which prevented the others from demangling
properly. Removing this logic for the other kinds of member operators
isn't causing any tests to fail.
We plan to replace the existing mechanism for overriding detection with
one that doesn't require the use of a special section as an alternative
to llvm/llvm-project#120805 which had other downsides.
This change is a pure refactoring that lays the foundation for a
subsequent change that will introduce the new detection mechanism.
I noticed that there are test-cases that are commented out. But the
manglings for them seem to be impossible to generate from valid C++. I
added two test-cases generated from following C++ program:
```
struct X {
int func() const && { return 5; }
const int &&func2() { return 5; }
const int &&func3(const int &x) volatile { return 5; }
};
void f(int (X::*)() const &&, int const && (X::*)(),
int const && (X::*)(const int &) volatile) {}
int main() {
f(&X::func, &X::func2, &X::func3);
return 0;
}
```
This patch includes the necessary changes for the LLDB feature proposed
in
https://discourse.llvm.org/t/rfc-lldb-highlighting-function-names-in-lldb-backtraces/85309.
The TL;DR is that we want to track where certain parts of a demangled
name begin/end so we can highlight them in backtraces.
We introduce a new `printLeft`/`printRight` API on `OutputBuffer` that a
client (in our case LLDB) can implement to track state while printing
the demangle tree. This requires redirecting all calls to to
`printLeft`/`printRight` to the `OutputBuffer`. One quirk with the new
API is that `Utility.h` would now depend on `ItaniumDemangle.h` and
vice-versa. To keep these files header-only I made the definitions
`inline` and implement the new APIs in `ItaniumDemangle.h` (so the
definition of `Node` is available to them).
Also introduces `notifyInsertion`/`notifyDeletion` APIs that a client can override to respond to cases where the `OutputBuffer` changes arbitrary parts of the name.
The qualifier allows programmer to directly control how pointers are
signed when they are stored in a particular variable.
The qualifier takes three arguments: the signing key, a flag specifying
whether address discrimination should be used, and a non-negative
integer that is used for additional discrimination.
```
typedef void (*my_callback)(const void*);
my_callback __ptrauth(ptrauth_key_process_dependent_code, 1, 0xe27a) callback;
```
Co-Authored-By: John McCall rjmccall@apple.com
