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
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.
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>.
Instead of building the benchmarks separately via CMake and running them
separately from the test suite, this patch merges the benchmarks into
the test suite and handles both uniformly.
As a result:
- It is now possible to run individual benchmarks like we run tests
(e.g. using libcxx-lit), which is a huge quality-of-life improvement.
- The benchmarks will be run under exactly the same configuration as
the rest of the tests, which is a nice simplification. This does
mean that one has to be careful to enable the desired optimization
flags when running benchmarks, but that is easy with e.g.
`libcxx-lit <...> --param optimization=speed`.
- Benchmarks can use the same annotations as the rest of the test
suite, such as `// UNSUPPORTED` & friends.
When running the tests via `check-cxx`, we only compile the benchmarks
because running them would be too time consuming. This introduces a bit
of complexity in the testing setup, and instead it would be better to
allow passing a --dry-run flag to GoogleBenchmark executables, which is
the topic of https://github.com/google/benchmark/issues/1827.
I am not really satisfied with the layering violation of adding the
%{benchmark_flags} substitution to cmake-bridge, however I believe
this can be improved in the future.
Instead of placing artifacts for testing the runtimes at <build>/test,
place those artifacts at <build>/<project>/test. This prevents
cluttering the build directory with the runtimes' test artifacts for
everyone else.
As a drive-by, remove LIBCXX_BINARY_INCLUDE_DIR which wasn't used
anymore.
This removes the need for macOS nodes in Buildkite. It also moves to the
proper way of testing backdeployment, which is to actually run on the
target OS itself, instead of using packaged dylibs from previous OS
versions and trying to emulate backdeployment with DYLD_LIBRARY_PATH.
As a drive-by change, also fix a few back-deployment annotations that
were incorrect and add support for minor versions in the Lit feature
determining availability from the target triple.
This is what we started doing in libc++ and it straightens up a lot of
things that only happened to work before, notably the presence of
relative rpaths in dylibs when running from the build tree.
This unlocks the ability to link against a just-built dylib but run
against another version of the dylib (for example the system-provided
one), which is necessary for proper backdeployment testing.
This patch adds a lot of code duplication between the libc++ and
libc++abi testing setups. However, there is already a large amount of
duplication and the only real way to get rid of it is to merge libc++abi
into libc++. In a way, this patch is a step in that direction because it
closes the gap between the two libraries' testing setup.
When demangling a template template parameter (`method<bool,
Bar>(Bar<bool> b)`), the current demangler version first enters the
template argument (`bool`) into the substitutions list, then the whole
template specialization (`Bar<bool>`). The template name (`Bar`) never
becomes a substitution candidate on its own.
This is different when mangling. Mangling `method<bool, Bar>(Bar<bool>
b, Bar<int> i)` substitutes the `Bar` in the second parameter with the
substitution for `TemplateTemplateParmDecl`.
This leads to a discrepancy between mangler and demangler, see
https://github.com/llvm/llvm-project/issues/108009.
This improves the demangling for non-type template arguments that
contain string literals. Previously we'd produce
char [4]{(char)65, (char)66, (char)67}
(which isn't valid C or C++), and now we produce `"ABC"`.
The new demangling is always shorter, even when using an escape sequence
for every character, and much more readable when the char array contains
text.
This fixes testing with MinGW, if built without
__USE_MINGW_ANSI_STDIO=1.
On x86 MinGW, such a configuration fails printf tests with long doubles
due to mismatches between 80 and 64 bit long doubles - but on ARM,
there's no such issue, so building without __USE_MINGW_ANSI_STDIO=1 is
perfectly valid there.
Add another similar XFAIL to a libcxxabi test; this test isn't executed
in MSVC environments, so no XFAIL has been needed so far.
In order to test libc++ under the "Apple System Library" configuration,
we need to run the tests using DYLD_LIBRARY_PATH. This is required
because libc++ gets an install_name of /usr/lib when built as a system
library, which means that we must override the copy of libc++ used by
the whole process. This effectively reverts 2cf2f1b, which was the wrong
solution for the problem I was having.
Of course, this assumes that the just-built libc++ is sufficient to
replace the system library, which is not actually the case
out-of-the-box. Indeed, the system library contains a few symbols that
are not provided by the upstream library, leading to undefined symbols
when replacing the system library by the just-built one.
To solve this problem, we separately build shims that provide those
missing symbols and we manually link against them when we build
executables in the tests. While this is somewhat brittle, it provides a
localized and unintrusive way to allow testing the Apple system
configuration in an upstream environment, which has been a frequent
request.
GCC 14 has been released a while ago. We've updated the CI to use GCC 14
now. This removes any old annotations in the tests and updates the
documentation to reflect the updated version requirements.
This adds a new `__cxa_call_terminate`, which GCC 14 generates calls to
now. Clang had `__clang_call_terminate` for the same use-case for a long
time. It also fixes a test that is enabled now, since GCC has the
`__has_feature` FTM now.
This patch removes many annotations that are not relevant anymore since
we don't support or test back-deploying to macOS < 10.13. It also cleans
up raw usage of target triples to identify versions of dylibs shipped on
prior versions of macOS, and uses the target-agnostic Lit features
instead. Finally, it reorders both the Lit backdeployment features and
the corresponding availability macros in the library in a way that makes
more sense, and reformulates the Lit backdeployment features in terms of
when a version of LLVM was introduced instead of encoding the system
versions on which it hasn't been introduced yet. Although one can be
derived from the other, encoding the negative form is extremely
error-prone.
Fixes#80901
We were not making any distinction between e.g. the "Apple-flavored"
libc++ built from trunk and the system-provided standard library on
Apple platforms. For example, any test that would be XFAILed on a
back-deployment target would unexpectedly pass when run on that
deployment target against the tip of trunk Apple-flavored libc++. In
reality, that test would be expected to pass because we're running
against the latest libc++, even if it is Apple-flavored.
To solve this issue, we introduce a new feature that describes whether
the Standard Library in use is the one provided by the system by
default, and that notion is different from the underlying standard
library flavor. We also refactor the existing Lit features to make a
distinction between availability markup and the library we're running
against at runtime, which otherwise limit the flexibility of what we can
express in the test suite. Finally, we refactor some of the
back-deployment versions that were incorrect (such as thinking that LLVM
10 was introduced in macOS 11, when in reality macOS 11 was synced with
LLVM 11).
Fixes#82107
This patch makes a few adjustments to the way we run the tests in the
Apple configuration on macOS:
First, we stop using DYLD_LIBRARY_PATH. Using that environment variable
leads to libc++.dylib being replaced by the just-built one for the whole
process, and that assumes compatibility between the system-provided
dylib and the just-built one. Unfortunately, that is not the case
anymore due to typed allocation, which is only available in the system
one. Instead, we want to layer the just-built libc++ on top of the
system-provided one, which seems to be what happens when we set a rpath
instead.
Second, add a missing XFAIL for a std::print test that didn't work as
expected when building with availability annotations enabled. When we
enable these annotations, std::print falls back to a non-unicode and
non-terminal output, which breaks the test.
Instead of using FOO_TEST_DEPS global variables that don't get updated
properly from subdirectories, use targets to propagate the dependencies
across directories.
A while back, the cxx_under_test Lit parameter was removed. This patch
reintroduces a Lit parameter called "compiler" which controls the value
of the %{cxx} substitution used in the test suite.
To run the test suite with a different compiler, one can now pass
--param compiler=<path>.
The Itanium C++ ABI specifies that FP literals are encoded using a
lowercase hexadecimal string. Previously, libc++abi allowed uppercase
A-F characters but decoded them by subtracting 'a' from them, producing
negative digit values. It is especially confusing to accept an 'E' digit
because 'E' marks the end of the FP literal.
Previously, the list of libc++abi symbols that we re-export from libc++
would be partly encoded in libc++abi (and re-exported automatically via
the cxxabi-reexports target), and partly hard-coded in
libcxx/lib/libc++abi.exp. The duplication of information led to symbols
not being exported from libc++ after being added to libc++abi when they
should have been.
This patch removes the duplication of information. After this patch, the
full list of symbols to re-export from libc++abi is handled by the
cxxabi-reexports target and is stored in libcxxabi.
The symbols newly re-exported from libc++ are mainly new fundamental
typeinfos and a bunch of functions and classes that are part of
libc++abi but are most likely implementation details. In the future, it
would be possible to try to trim down the set of what we export from
libc++abi (and hence what we re-export from libc++) to remove some
implementation detail symbols.
Fixes#79008
Chrome rolls libc++ and libc++abi as separate projects. As a result, they
may not always be updated in lockstep, and this can lead to build failures
when mixing libc++ that doesn't have <__thread/support.h> with libc++abi
that requires it.
This patch adds a workaround to make libc++abi work with both versions.
While Chrome's setup is not supported, this workaround will allow them
to go back to green and do the required work needed to roll libc++ and
libc++abi in lockstep. This workaround will be short-lived -- I have a
reminder to go back and remove it by EOW.
The <__threading_support> header is a huge beast and it's really
difficult to navigate. I find myself struggling to find what I want
every time I have to open it, and I've been considering splitting it up
for years for that reason.
This patch aims not to contain any functional change. The various
implementations of the threading base are simply moved to separate
headers and then the individual headers are simplified in mechanical
ways. For example, we used to have redundant declarations of all the
functions at the top of `__threading_support`, and those are removed
since they are not needed anymore. The various #ifdefs are also
simplified and removed when they become unnecessary.
Finally, this patch adds documentation for the API we expect from any
threading implementation.
This addresses cases (currently failing) where we throw a null
pointer-to-object and fixes#64953.
We are trying to satisfy the following bullet from the C++ ABI 15.3:
* the handler is of type cv1 T* cv2 and E is a pointer type that can be
converted to the type of the handler by either or both of:
- a standard pointer conversion (4.10 [conv.ptr]) not involving
conversions to private or protected or ambiguous classes.
- a qualification conversion.
The existing implementation assesses the ambiguity of bases by computing
the offsets to them; ambiguous cases are then when the same base appears
at different offsets. The computation of offset includes indirecting
through the vtables to find the offsets to virtual bases.
When the thrown pointer points to a real object, this is quite efficient
since, if the base is found, and it is not ambiguous and on a public
path, the offset is needed to return the adjusted pointer (and the
indirections are not particularly expensive to compute).
However, when we throw a null pointer-to-object, this scheme is no
longer applicable (and the code currently bypasses the relevant
computations, leading to the incorrect catches reported in the issue).
-----
The solution proposed here takes a composite approach:
1. When the pointer-to-object points to a real instance (well, at least,
it is determined to be non-null), we use the existing scheme.
2. When the pointer-to-object is null:
* We note that there is no real object.
* When we are processing non-virtual bases, we continue to compute the
offsets, but for a notional dummy object based at 0. This is OK, since
we never need to access the object content for non-virtual bases.
* When we are processing a path with one or more virtual bases, we
remember a cookie corresponding to the inner-most virtual base found so
far (and set the notional offset to 0). Offsets to inner non-virtual
bases are then computed as normal.
A base is then ambiguous iff:
* There is a recorded virtual base cookie and that is different from the
current one or,
* The non-virtual base offsets differ.
When a handler for a pointer succeeds in catching a base pointer for a
thrown null pointer-to-object, we still return a nullptr (so the
adjustment to the pointer is not required and need not be computed).
Since we noted that there was no object when starting the search for
ambiguous bases, we know that we can skip the pointer adjustment.
This was originally uploaded as https://reviews.llvm.org/D158769.
Fixes#64953
When lpStartEncoding is different from DW_EH_PE_omit, lpStart can be set
to zero which is a valid base address for landing pads. Such base value
is useful when landing pads are placed in different sections.
Fixes#72582.
This patch actually runs the tests for picolibc behind an emulator,
removing a few workarounds and increasing coverage.
Differential Revision: https://reviews.llvm.org/D155521
Picolibc is a C Standard Library that is commonly used in embedded
environments. This patch adds initial support for this configuration
along with pre-commit CI. As of this patch, the test suite only builds
the tests and nothing is run. A follow-up patch will make the test suite
actually run the tests.
Differential Revision: https://reviews.llvm.org/D154246
The mangling for an explicitly named object was introduced in
https://reviews.llvm.org/D140828
See following discussion for why a new mangling had to be introduced:
https://github.com/itanium-cxx-abi/cxx-abi/issues/148
Since clang started emitting names with the new mangling, this patch
implements support for demangling such names.
The approach this patch takes is to add a new `ExplicitObjectParameter`
node that will print the first parameter of a function declaration with
a `this ` prefix, to reflect what was spelled out in source.
Example:
```
void MyClass::func(this MyClass const& self); // _ZNH7MyClass4funcERKS_
```
With this patch, the above demangles to:
```
_ZNH7MyClass4funcERKS_ -> MyClass::func(this MyClass const&)
```
Note that `func` is not marked as `const &`, since the
function-qualifiers are now encoded as part of the explicit `this`. C++
doesn't allow specifying the function-qualifiers in the presence of an
explicit object parameter, so this demangling is consistent with the
source spelling.
Adding test-cases to the `cases` array causes `git clang-format` to
split the strings of many of the existing test-cases, making them harder
to read/work with in most cases.
This patch disables `clang-format` for the `cases` array so it doesn't
catch anyone off-guard in the future.
The runtimes now have a principled way of doing assertions in relation
to hardening, so we should use that instead of raw calls to assert()
inside libc++abi. This patch aims to maintain the behavior of the
demangler code when it is used from within LLVM by introducing a simple
DEMANGLE_ASSERT(...) macro that is then defined to the appropriate
assertion mechanism.
This will allow for configuring tests according to AIX version.
Reviewed By: daltenty, #libc, Mordante
Differential Revision: https://reviews.llvm.org/D149660
