This essentially copies the `.clang-tidy` file from libc++ into
libc++abi, except that the naming conventions are updated to not add
underscores and some checks are disabled that don't pass currently. They
will be fixed in follow-ups.
On Wasm, it's not currently possibly to change which `personality` is
attached to a given IR function. This is primarily because no matter
what `personality` is attached, codegen creates a call to a
`Unwind_CallPersonality` wrapper hard-coded to call c++abi's
personality.
In order to allow alternative personalities without introducing bloat at
each personality call site, this PR adjusts the ABI of the personality
on Wasm. `Unwind_CallPersonality` is moved to `libcxxabi` under the name
`__gxx_wasm_personality_v0`, with the "real" personality code renamed
`__gxx_personality_imp` and called by `__gxx_wasm_personality_v0` (after
resetting the landing pad context).
The signature of EH personalities on Wasm is now `int personality(void*
exception_object)` (where the int return is `_Unwind_Reason_Code` and
the `void*` is `_Unwind_Exception*`), and personalities are expected to
`__wasm_lpad_context.selector = 0;`.
Based on #175202
We found out that the new mechanism for detecting overriden functions
does not support Arm Pointer Authentication (PAuth). Addressing this
limitation is going to require changes to Clang. In the meantime, we
switched back to the old mechanism when PAuth is enabled.
This update removes some unnecessary carveouts, marks some newly
XFAILing tests, and unmarks some now passing tests.
With this change the status of tests is:
Total Discovered Tests: 11471
Unsupported : 2098 (18.29%)
Passed : 9260 (80.73%)
Expectedly Failed: 113 (0.99%)
Assisted-by: Automated tooling, human reviewed.
We already use the C++11 spelling for libc++, and there isn't much of a
reason not to use it. Except for the changes in `cxxabi.h` this is even
fully standard code.
This option is supported (and hence gets added by the
target_add_compile_flags_if_supported function) on Windows, but if using
dllexport, there's no point in using hidden visibility. (However if
building both static and shared libraries at the same time, it could be
beneficial to have hidden visibilty in the static libraries.)
In asserts enabled builds of Clang, building with -fvisibility=hidden
caused errors like this:
dllexport GlobalValue must have default or protected visibility
ptr @_ZTIv
[...]
fatal error: error in backend: Broken module found, compilation aborted!
Normally, combining -fvisibility=hidden with dllexport is not a problem,
but specifically for `__cxxabiv1:: __fundamental_type_info` it does make
Clang trigger an inconsistency, visible in asserts enabled builds of
Clang - see https://github.com/llvm/llvm-project/issues/207963.
This fixes Windows builds with Clang with asserts enabled, after
cb942d009a.
Building with `-fvisibility=hidden` is generally a good idea, since it
avoids unnecessary relocations when loading a dylib. For libc++abi this
should be a no-op, since most things are annotated explicitly. By
enabling `-fvisibility=hidden` we can remove these explicit annotations
however.
Re-indent the shared library target blocks that were wrapped in
if(<runtime>_SUPPORTS_SHARED_LIBRARY) in the previous commit. This is a
whitespace-only change split out from the functional change to keep that
diff minimal and reviewable.
Co-authored-by: Claude (Opus 4.8) <noreply@anthropic.com>
On platforms that don't support shared libraries (e.g. CMAKE_SYSTEM_NAME
of "Generic", used for GPU and other baremetal targets), CMake's
Platform/Generic.cmake sets the global TARGET_SUPPORTS_SHARED_LIBS
property to FALSE. Under CMP0164's OLD behavior (the default, since the runtimes
set cmake_minimum_required(3.20)), CMake silently demotes SHARED library
targets to STATIC archives. libcxx, libcxxabi and libunwind always create their
shared target, so after demotion both the shared and static targets emit e.g.
"libc++abi.a" and Ninja fails with "multiple rules generate ...".
Rather than papering over the collision with a distinct output name,
skip creating the shared library targets entirely when the platform does not
support them, gating on the TARGET_SUPPORTS_SHARED_LIBS property (left
undefined on platforms that do support shared libraries). The few consumers of
the shared targets are guarded with TARGET checks so they fall back to the static
library or are skipped.
Also set policy CMP0164 to NEW so that any future unguarded
add_library(... SHARED ...) on an unsupported platform fails at
configure time instead of silently producing a colliding static archive.
See https://gitlab.kitware.com/cmake/cmake/-/issues/25759.
The bodies of the newly-conditional blocks are left at their original
indentation to keep this diff minimal. A follow-up commit will fix the
indentation. This was mostly AI generated with some comment fixups.
Co-authored-by: Claude (Opus 4.8) <noreply@anthropic.com>
clang-tidy currently doesn't run in the CI because CMake doesn't find
the appropriate `ClangConfig.cmake` anymore. This adds the path so
clang-tidy is built again and fixes most issues. Some things are
disabled for now to get most checks back. They will be re-enabled later.
This updates the DEMANGLE_ABI annotation to only be defined if it is not
already defined. This is required to parse the Demangle headers with the
ids-check script.
In addition, this adds one missing DEMANGLE_ABI annotation.
This effort is tracked in #109483.
macOS 26.4 and aligned platforms have been released and they are roughly
synchronized to libc++ 21. As a drive-by, also add missing versions for
previous releases.
This also allows reverting #199682 which moved an XFAIL to UNSUPPORTED
to silence CI failures temporarily.
ARM EHABI builds of libcxxabi fail with clang-22+ because
cxa_personality.cpp calls __gnu_unwind_frame without a visible
declaration, triggering:
error: use of undeclared identifier '__gnu_unwind_frame'
Add an extern "C" forward declaration before the EHABI unwind helper so
the source compiles correctly.
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
This patch adds a CMake cache, and the testing configs to build libc++
and run the tests against LLVM libc.
Reviewers: ldionne, philnik777, jtstogel
Pull Request: https://github.com/llvm/llvm-project/pull/165120
Update the Itanium demangler to recognize and strip `__alloc_token_`
prefixes introduced by AllocToken instrumentation [1]. This ensures that
instrumented allocation functions (e.g., `__alloc_token__Znwm`) demangle
back to their original source-level names (e.g., `operator new(unsigned
long)`) with a suffix `(.alloc_token)` indicating their non-standard
origin.
Since AllocToken is intended to be transparent to users who continue to
use `operator new` as before, the demangled name should reflect this
reality instead of confusing users with internal instrumentation names
in stack traces or symbolization output.
Synchronize changes across llvm and libcxxabi copies.
[1] https://clang.llvm.org/docs/AllocToken.html
Original RFC: https://discourse.llvm.org/t/rfc-a-framework-for-allocator-partitioning-hints/87434
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.
4eed68357e 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
