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
PowerPC uses a slightly different type of floats for their 128 bit long
doubles, as "double-double", with __LDBL_MANT_DIG__ == 106 rather than
__LDBL_MANT_DIG__ == 113 for IEEE 128 bit floats.
This fixes compiling libcxxabi for PowerPC after
3b70715c13876c51542ebfe2e3f4ee908f6785cb.
This avoids needing to hardcode the mapping between architectures and
their sizes of long doubles.
This fixes a case in test_demangle.pass.cpp, that previously failed like
this (XFAILed):
.---command stdout------------
| Testing 29859 symbols.
| _ZN5test01hIfEEvRAcvjplstT_Le4001a000000000000000E_c should be invalid
but is not
| Got: 0, void test0::h<float>(char (&) [(unsigned int)(sizeof (float) +
0x0.07ff98f7ep-1022L)])
`-----------------------------
.---command stderr------------
| Assertion failed: !passed && "demangle did not fail", file
libcxxabi/test/test_demangle.pass.cpp, line 30338
`-----------------------------
This testcase is defined within
// Is long double fp80? (Only x87 extended double has 64-bit mantissa)
#define LDBL_FP80 (__LDBL_MANT_DIG__ == 64)
...
#if !LDBL_FP80
...
#endif
The case failed on x86 architectures with an unusual size for long
doubles, as the test expected the demangler to not be able to demangle
an 80 bit long double (based on the `__LDBL_MANT_DIG__ == 64` condition
in the test). However as the libcxxabi implementation was hardcoded to
demangle 80 bit long doubles on x86_64 regardless of the actual size,
this test failed (by unexpectedly being able to demangle it).
By configuring libcxxabi's demangling of long doubles to match what the
compiler specifies, we no longer hit the expected failures in the
test_demangle.pass.cpp test on Android on x86.
This makes libcxxabi require a GCC-compatible compiler that defines
nonstandard defines like `__LDBL_MANT_DIG__`, but I presume that's
already essentially required anyway.
Requirements on character-like types are updated unconditionally,
because `basic_string` does requires the default-constructibility. It
might be possible to make `basic_string_view` support classes with
non-public trivial default constructor, but this doesn't seem sensible.
libcxxabi's `ItaniumDemangle.h` is also updated to avoid deprecated
features.
This makes it clearer that initialization of this global variable is
taking place at compile-time, reducing the likelihood of static
initialization order fiasco.
There doesn't seem to be much benefit in always providing declarations
for the sized deallocations from C++14 onwards if the user explicitly
passed `-fno-sized-deallocation` to disable them. This patch simplifies
the declarations to be available exactly when the compiler expects sized
deallocation functions to be available.
This was needed before https://github.com/llvm/llvm-project/pull/115077
since the compiler-rt test build made assumptions about the build
layout of libc++ and libc++abi, but now they link against a local
installation of these libraries so we no longer need this workaround.
This mechanism is preferable in environments like embedded since it
doesn't require special handling of the custom section.
This is a reland of https://github.com/llvm/llvm-project/pull/114961
which addresses the issue reported by downstream users. Specifically,
the two differences from the previous version are:
* The internal `symbol##_impl__` symbol in the Mach-O implementation is
annotated with `__attribute__((used))` to prevent LTO from deleting it
which we've seen in the previous version.
* `__is_function_overridden` is marked as `inline` so these symbols are
placed in a COMDAT (or fully inlined) to avoid duplicate symbol errors
which we've seen in the previous version.
This disentangles the code which previously had a mix of many #ifdefs, a
non-versioned namespace and a versioned namespace. It also makes it
clearer which parts of <new> are implemented on Windows by including <new.h>.
When using LTO, the deplibs mechanism is insufficient to ensure that
libzircon is always brought into the link prior to LTO code generation.
The general problem is discussed in depth in
https://github.com/llvm/llvm-project/issues/56070
To work around this, we can just provide libzircon as a link input.
The variables are all `constexpr`, which implies `inline`. Since they
aren't `constexpr` in C++03 they're also not `inline` there. Because of
that we define them out-of-line currently. Instead we can use the C++17
extension of `inline` variables, which results in the same weak
definitions of the variables but without having all the boilerplate.
