This is a variant of D116689 rebased on top of the new (proposed) ABI
refactoring in D120727. It should conserve the basic properties of the
original patch by @phosek, except it also allows cleaning up the merging
of libc++abi into libc++ from the libc++ side.
Differential Revision: https://reviews.llvm.org/D125393
Prior to D120727, the libcxx build was responsible for copying libcxxabi
headers into the right location, both in the build and install trees,
but now it's the responsibility of the libcxxabi build. While the build
already did the right thing for the install tree, it wouldn't copy
headers into the build tree, resulting in errors when trying to use the
just built toolchain as is the case in the runtimes build when building
compiler-rt runtimes.
Differential Revision: https://reviews.llvm.org/D125597
Standalone builds have been deprecated and then removed for a while now.
Trying to use standalone builds leads to a fatal CMake error, so this
code is all dead. Remove it to clean things up.
Differential Revision: https://reviews.llvm.org/D125561
This keeps the same logic, but uses early return to avoid multiple layers
of nested ifs and make the code simpler to follow.
Differential Revision: https://reviews.llvm.org/D125476
This patch overhauls how we pick up the ABI library. Instead of setting
ad-hoc flags, it creates interface targets that can be linked against by
the rest of the build, which is easier to follow and extend to support
new ABI libraries.
This is intended to be a NFC change, however there are some additional
simplifications and improvements we can make in the future that would
require a slight behavior change.
Differential Revision: https://reviews.llvm.org/D120727
We need to expand special substitutions in four different ways. This
refactors to only have one conversion from enum to string, and derive
the other 3 needs off that.
The SpecialSubstitution node is derived from the
ExpandedSpecialSubstitution. While this may seem unintuitive, it
works out quite well, as SpecialSubstitution can then use the former's
getBaseName and remove an unneeded 'basic_' prefix, for those
substitutions that are instantiations (to known typedef). Similarly
all those instantiations use the same set of template arguments (with
'basic_string', getting an additional 'allocator' arg).
Expansion tests were added in D123134, and remain unchanged.
Reviewed By: MaskRay, dblaikie
Differential Revision: https://reviews.llvm.org/D125257
As a fly-by fix, also let `__cxa_demangle` allocate its buffer alone,
since we are not allowed to pass a non-malloc'd buffer to it.
Differential Revision: https://reviews.llvm.org/D125268
When we terminate due to an exception being uncaught, libc++abi prints
a message saying "terminating with uncaught exception [...]". This patch
changes that to say "terminating due to uncaught exception [...]" instead,
which is a bit clearer. Indeed, I've seen some people being confused and
thinking that libc++abi was the component throwing the exception.
Differential Revision: https://reviews.llvm.org/D125245
With the demangler parenthesizing 'a >> b' inside template parameters,
because C++11 parsing of >> there, we don't really need to add spaces
between adjacent template arg closing '>' chars. In 2022, that just
looks odd.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D123134
The output buffer has a 'back' member, which returns NUL when you try
it with an empty buffer. But there are no use cases that need that
additional functionality. This makes the 'back' member behave more
like STL containers' back members. (It still returns a value, not a
reference.)
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D123201
On Windows on i386, C++ member functions use a different calling
convention (`__thiscall`) than the default one for regular functions
(`__cdecl`). (On Windows on architectures other than i386, both calling
convention attributes are no-ops.)
This matches how libstdc++ declares these types.
This fixes the std/thread/futures/futures.{shared,unique}_future/dtor.pass.cpp
tests on i386 mingw.
Differential Revision: https://reviews.llvm.org/D124990
(Exitingly) a fold expression's operators include .* and ->*, but we
failed to demangle them as we categorize those as MemberExprs, not
BinaryExprs.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D123305
When the sigreturn trampoline is found the unw_proc_info_t.end_ip need to be set to
indicate a stack frame is found.
Reviewed By: cjdb, #libunwind, MaskRay
Differential Revision: https://reviews.llvm.org/D124522
Every non-testcase use of OutputBuffer contains code to allocate an
initial buffer (using either 128 or 1024 as initial guesses). There's
now no need to do that, given recent changes to the buffer extension
heuristics -- it allocates a 1k(ish) buffer on first need.
Just pass in a buffer (if any) to the constructor. Thus the
OutputBuffer's ownership of the buffer starts at its own lifetime
start. We can reduce the lifetime of this object in several cases.
That new constructor takes a 'size_t *' for the size argument, as all
uses with a non-null buffer are passing through a malloc'd buffer from
their own caller in this manner.
The buffer reset member function is never used, and is deleted.
The original buffer initialization code would return a failure code if
that first malloc failed. Existing code either ignored that, called
std::terminate with a FIXME, or returned an error code.
But that's not foolproof anyway, as a subsequent buffer extension
failure ends up calling std::terminate. I am working on addressing
that unfortunate failure mode in a manner more consistent with the C++
ABI design.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D122604
Placing a run-once test inside the operator lookup function caused
problems with the thread sanitizer. See D122975.
Break out the operator table into a member variable, and move the test
to the unit test machinery.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D123390
Avoid repeating CMake checks across runtimes by unifying names of
variables used for results to leverage CMake caching.
Differential Revision: https://reviews.llvm.org/D110005
The underlying TLS destruction order bug has been fixed in the OS. This
would technically still fail when running on top of macOS < 12, however
we don't have a good way of encoding that using Lit features. Indeed,
the existing target=<FOO> Lit feature encodes the deployment target,
not the actual runtime system that the tests are being run on.
If this test starts failing on your machine after this patch, upgrading
to macOS 12 should solve the problem.
The demangler has a utility class 'SwapAndRestore'. That name is
confusing. It's not swapping anything, and the restore part happens at
the object's destruction. What it's actually doing is allowing a
override of some value that is dynamically accessible within the
lifetime of a lexical scope. Thus rename it to ScopedOverride, and
tweak it's member variable names.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D122606
GCC emits [some] static symbols with an 'L' mangling, which we attempt
to demangle. But the module mangling changes have exposed that we
were doing so at the wrong level. Such manglings are outside of the
ABI as they are internal-linkage, so a bit of reverse engineering was
needed. This adjusts the demangler along the same lines as the
existing gcc demangler (which is not yet module-aware). 'L' is part
of an unqualified name. As before we merely parse the 'L', and then
ignore it.
Reviewed By: iains
Differential Revision: https://reviews.llvm.org/D123138
Both > and >> expressions need to be parenthesized inside template
argument lists.
Reviewed By: dblaikie, rjmccall
Differential Revision: https://reviews.llvm.org/D122474
* Add instantiation tests to ItaniumDemangleTest, to make sure all
match functions provide constructor arguments to the provided functor.
* Fix the Node constructors that lost const qualification on arguments.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D122665
In order to add a unit test, we need to expose the node names beyond
ItaniumDemangle.h. This breaks them out into a def file.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D122739
This allows us to detect whether we're being compiled with LLVM's libunwind
more easily, without CMake having to set explicit variables.
As discussed in https://llvm.org/D119538.
Differential Revision: https://reviews.llvm.org/D121015
Each demangler node's match function needs to call the provided
functor with constructor arguments. That was omitted from D120905.
This adds the new Precedence argument where necessary (and a missing
boolean for a module node).
The two visitors need updating with a printer for that type, and this
adds a stub to cxa_demangle's version. blaikie added one to llvm's.
I'll fill out those printers in a followup, rather than wait, so that
downstream consumers are unbroken.
This means that re-running with llvm-lit in that configuration will
work as expected. This also enables assertions in libc++abi in the
Generic-assertions CI job, which was disabled previously.
Differential Revision: https://reviews.llvm.org/D122597
The OutputBuffer class tries to present a NUL-terminated string API to
consumers. But several of them would prefer a StringView. In
particular the Microsoft demangler, juggles between NUL-terminated and
StringView, which is confusing.
This adds a StringView conversion, and adjusts the Demanglers that can
benefit from that.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D120990
The demangler had no concept of operator precendence, and would
parenthesize many more subexpressions than necessary. In particular
it would parenthesize primary-expressions, such as '4', which just
looks strange. It would also parenthesize '>' expressions, just in
case they were inside a template parameter list.
This patch fixes both issues.
* Add operator precedence to the OpInfo structure, and add a
subexpression helper that will parenthesize a lower precedence
subexpression.
* Add a 'greater-than is greater-than' indicator to the output buffer,
so the expression printer knows whether it is immediately inside a
template parameter list (and must therefore parenthesize 'expr >
expr'). This is a counter, so that ...
* Add open and close printers to the output buffer, that increment and
decrement the gt-is-gt indicator.
* Parenthesize comma operators inside comma-separated lists. (probably
a rare case, but still).
This dramatically reduces the extraneous parentheses being printed.
Reviewed By: dblaikie, bruno
Differential Revision: https://reviews.llvm.org/D120905
Add support for module name demangling. We have two new demangler
nodes -- ModuleName and ModuleEntity. The former represents a module
name in a hierarchical fashion. The latter is the combination of a
(name) node and a module name. Because module names and entity
identities use the same substitution encoding, we have to adjust the
flow of how substitutions are handled, and examine the substituted
node to know how to deal with it.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D119933
In the new-style testing configurations, we were hardcoding paths to the
`include` and `lib` directories, which was incorrect but always went
unnoticed because the hardcoded values always happened to match the
actual value.
When using new-style configs with the bootstrapping build, this falls
appart -- and we never noticed this because the bootstrapping build was
still using old style configs.
This patch removes the %{install} substitution, which makes it too
tempting to hardcode installation paths, and it also switches the
bootstrapping build to actually using new-style configs like we
always intended to do.
Differential Revision: https://reviews.llvm.org/D121700
The fix for D111703 clobbered r4 both to:
- Save/restore the original lr.
- Load the address of _Unwind_Resume for LIBCXXABI_BAREMETAL.
This patch saves and restores lr without clobbering any extra
registers.
For LIBCXXABI_BAREMETAL, it is still necessary to clobber one extra
register to hold the address of _Unwind_Resume, but it seems better to
use ip/r12 (intended for linker veneers/trampolines) than r4 for this
purpose.
The function also clobbers r0 for the _Unwind_Resume function's
parameter, but that is unavoidable.
Reviewed By: danielkiss, logan, MaskRay
Differential Revision: https://reviews.llvm.org/D121432
If LIBCXX_ENABLE_SHARED isn't explicitly set on the cmake command
line, isn't set in the cache, and the libcxxabi project is configured
before libcxx, then LIBCXX_ENABLE_SHARED isn't defined yet. Once
the libcxx cmake project has been parsed, LIBCXX_ENABLE_SHARED would
have been set to its default value of ON.
This makes sure that the symbols are properly dllexported in such
a configuration scenario.
Differential Revision: https://reviews.llvm.org/D120982
In addressing the buffer ownership API, I discovered a rogue member
function that returned by value rather than by reference. It clearly
intended to return by reference, but because the copy ctor wasn't
deleted this wasn't caught.
It is not necessary to make this a move-only type, although that would
be an alternative.
Reviewed By: bruno
Differential Revision: https://reviews.llvm.org/D120901
Using -isystem marks the headers as system headers, which means that we
don't actually get all the warnings that we'd normally get if we included
the headers as user headers.
The goal of the test suite is normally to mirror as closely as possible
how users would use the library. Technically, this change goes against
that philosophy, since users should be using `-isystem` (if they ever
need to specify the libc++ path explicitly, which should be a rare
occurence). However, I believe fishing out additional warnings from
the headers provides more value, hence this change. Ideally, we'd be
able to still use `-isystem`, but instruct Clang to still emit warnings
from the libc++ headers (e.g. we could tell Clang to emit warnings in
any file inside `<...>/usr/include/c++/v1`).
Reviewed By: #libc, ldionne, #libc_abi
Spies: Mordante, EricWF, mstorsjo, mgorny, aheejin, arichardson, philnik, jloser, libcxx-commits
Differential Revision: https://reviews.llvm.org/D118616
Instead, folks can use the equivalent variables provided by CMake
to set those. This removal aims to reduce complexity and potential
for confusion when setting the target triple for building the runtimes,
and make it correct when `CMAKE_OSX_ARCHITECTURES` is used (right now
both `-arch` and `--target=` will end up being passed, which is downright
incorrect).
Differential Revision: https://reviews.llvm.org/D112155
This commit reverts 5aaefa51 (and also partly 7f285f48e7 and b6d75682f9,
which were related to the original commit). As landed, 5aaefa51 had
unintended consequences on some downstream bots and didn't have proper
coverage upstream due to a few subtle things. Implementing this is
something we should do in libc++, however we'll first need to address
a few issues listed in https://reviews.llvm.org/D106124#3349710.
Differential Revision: https://reviews.llvm.org/D120683
The demangler doesn't understand 'aw' as an operator name. This adds
the necessary smarts -- you may use this as an operator functionname,
but not as an expression operator.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D120143
We need to parse operator names in 3 places -- expressions, names &
fold expressions. Currently we have 3 separate pieces to do this, and a FIXME.
The operator name and expression parsing are implemented as
handwritten two-character nested switches, the fold expression is a
sequence of string comparisons.
This adds a new OperatorInfo class to encode the operator info
(encoding, kind, name), and has a table that it can binary search.
From that each of the above 3 uses are altered to use the new scheme.
Existing tests cover parsing operator encodings.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119467
Improve demangler buffer hysteresis. If we needed more than double
the buffer, the original code would allocate exactly the amount
needed, and thus consequently the next request would also realloc.
We're very unlikely to get into wanting more than double, after the
first allocation, as it would require the user to have used an
identifier larger than the hysteresis. With machine generated code
that's possible, but unlikely.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119972
The SwapAndRestore class is over engineered. Nothing makes use of the
early restoration machinery. Let's just remove that cognative burdon.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D120673
