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
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
libc++abi should be responsible for installing its own headers, it
doesn't make sense for libc++ to be responsible for it.
Differential Revision: https://reviews.llvm.org/D101458
libc++ has started splicing standard library headers into much more
fine-grained content for maintainability. It's very likely that outdated
and naive tooling (some of which is outside of LLVM's scope) will
suggest users include things such as <__ranges/access.h> instead of
<ranges>, and Hyrum's law suggests that users will eventually begin to
rely on this without the help of tooling. As such, this commit
intends to protect users from themselves, by making it a hard error for
anyone outside of the standard library to include libc++ detail headers.
Differential Revision: https://reviews.llvm.org/D106124
The linter complains about the formatting in subsequent changes.
Fixing that now.
Reviewed By: iains
Differential Revision: https://reviews.llvm.org/D120117
The copy and pristine versions of Utility diverged and one didn't
include <algorithm>. As that's a rather large header, let's just open
code the comparisons.
Reviewed By:
Differential Revision: https://reviews.llvm.org/
parseNestedName's main loop allowed parsing a grammar that was more
flexible than the actual grammar. This refactors that to rule out
some more incorrect manglings.
1) The 'L' extension only applies to unqualified-name components, so
check it just there.
2) The 'M' suffix is, AFAICT, removed from the grammar. Rather than
eliminate it, let's parse it after we've parsed a component.
Added some additional bad mangling tests, which are now rejected.
I don't break the 'T' and 'D[tT]' cases out of the loop, even though
they can only appear at first position, as it seems simpler to just
check there is nothing SoFar.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119542
In src/, most files can use `constinit` directly because they're always
compiled with C++20. But some files, like "libcxxabi/src/fallback_malloc.cpp",
can't, because they're `#include`d directly from test cases in libcxxabi/test/
and therefore must (currently) compile as C++03. We might consider refactoring
those offending tests, or at least marking them `UNSUPPORTED: c++03`.
Differential Revision: https://reviews.llvm.org/D119264
We have to special-case 'u 8__uuidof [tz]' demangling for legacy
support. That handling is a little duplicative.
* It seems better to just push the single expected node.
* We can also use 'consumeIf' rather than open-coding the peeking and increment.
* We don't need the numLeft < 2 check, as if there are few than that
other paths will end up with detecting the error.
FWIW This simplifies a future change adding operator precedence.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119543
The output buffer growth algorithm had a few issues:
a) An off-by-one error in the initial size check, which uses
'>='. This error was safe, but could cause us to reallocate when there
was no need.
b) An inconsistency between the initial size check (>=) and the
post-doubling check (>). The latter was somewhat obscured by the
swapped operands.
c) There would be many reallocs with an initially-small buffer. Add a
little initialization hysteresis.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119177
The unqualified name grammar includes <ctor-dtor-name>, but we handle
that specially in parseNestedName. This is a little awkward. We can
pass in the current scope and have parseUnqualifiedName deal with
cdtors too. That also allows a couple of other simplifications:
1) parseUnqualifiedName can also build up the NestedName, when the
provided scope is non-null. Which means ...
2) parseUnscopedName can pass a "std" scope in (and tailcall).
3) ... and also parseNestedName need not construct the nestedname itself.
4) also parseNestedName's detection of a cdtor-name doesn't have to
rule out a decomposition name anymore.
This change also makes adding module demangling more
straight-forwards, btw.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119154
I discovered some demangler problems:
a) parsing of new expressions was broken, ignoring any 'gs' prefix
b) (when #a is fixed) badly formatted global new expressions
c) formatting of new and delete failed to correctly add whitespace
(a) happens as parseExpr swallows the 'gs' prefix but doesn't pass it
to 'parseNewExpr'. It seems simpler to me to just code the new
expression parsing directly in parseExpr, as is done for delete
expressions.
(b) global new should be rendered something like '::new T' not
'::operator new T'
(c) is resolved by being a bit more careful with whitespace.
Best shown with some examples (don't worry that these symbols are for
impossible instantiations, that's not the point):
Old behaviour:
build/bin/llvm-cxxfilt _ZN2FnIXgsnw_iEEXna_ipiLi4EEEEEvv _ZN2FnIXnwLj4E_iEEXgsnaLj4E_ipiLi4EEEEEvv _ZN2FnIXgsdlLi4EEXdaLi4EEEEvv _ZN2FnIXdlLj4EEXgsdaLj4EEEEvv
void Fn<new int, new[] int(4)>() // No ::new
void Fn<new (4u)int, new[] (4u)int(4)>() // No ::new, poor whitespace
void Fn<::delete4, delete[] 4>() // missing necessary space
void Fn<delete4u, ::delete[] 4u>() // missing necessary space
New behaviour:
build/bin/llvm-cxxfilt _ZN2FnIXgsnw_iEEXna_ipiLi4EEEEEvv _ZN2FnIXnwLj4E_iEEXgsnaLj4E_ipiLi4EEEEEvv _ZN2FnIXgsdlLi4EEXdaLi4EEEEvv _ZN2FnIXdlLj4EEXgsdaLj4EEEEvv
void Fn<::new int, new[] int(4)>()
void Fn<new(4u) int, ::new[](4u) int(4)>()
void Fn<::delete 4, delete[] 4>()
void Fn<delete 4u, ::delete[] 4u>()
Binutils' behaviour:
c++filt _ZN2FnIXgsnw_iEEXna_ipiLi4EEEEEvv _ZN2FnIXnwLj4E_iEEXgsnaLj4E_ipiLi4EEEEEvv _ZN2FnIXgsdlLi4EEXdaLi4EEEEvv _ZN2FnIXdlLj4EEXgsdaLj4EEEEvv
void Fn<::new int, new int(4)>()
void Fn<new (4u) int, ::new (4u) int(4)>()
void Fn<::delete (4), delete[] (4)>()
void Fn<delete (4u), ::delete[] (4u)>()
The new and binutils demanglings are the same modulo some whitespace and optional parens.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D118476
a) Using a do...while loop in the number formatter means we do not
have to special case zero.
b) Let's use 'if (auto size = ...) {}' for appending to the output
buffer.
c) We should also be using memcpy there, not memmove -- the string
being appended is never part of the current buffer.
d) Let's put all the operator<< functions together.
e) I find 'if (cond) frob(..., true) ; elseOD frob(..., false)'
somewhat confusing. Let's just use std::abs in the signed integer
printer and let CSE decide about the duplicate < 0 testing.
f) Let's have as many as possible return *this. That's both more
consistent, and allows tailcalls in some cases (the actual number
formatter has a local array though).
These changes removed around 100 bytes from the demangler's
instructions on x86_64.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119176
The demangler treats ->* as a BinaryExpr, but .* as a MemberExpr.
That's inconsistent. This makes the former a MemberExpr too.
However, in order to not regress the paren output, MemberExpr::print
is modified to parenthesize the MemberExpr if the operator ends with
'*'. Printing is affected thusly:
Before:
obj.member
obj->member
obj.*member
(obj) ->* (member)
After:
obj.member # Unchanged
obj->member # Unchanged
obj.*(member) # Added paren member operand
obj->*(member) # Removed paren on object operand, less whitespace
The right solution to the paren problem is to add some notion of
precedence (and associativity) to Nodes, but that's a larger change
that would become simpler once the refactoring I'm doing is completed.
FWIW, binutils' demangler's paren algorithm has a small idea of
precedence, and will generally not emit parens when the operand is
unary.
Reviewed By: bruno
Differential Revision: https://reviews.llvm.org/D118486
The parsing of nested names is a little lax. This corrects that.
1) The 'L' local name prefix cannot appear before a NestedName -- only
within it. Let's remove that check from parseName, and then adjust
parseUnscopedName to allow it with or without the 'St' prefix.
2) In a nested name, a <template-param>, <decltype> or <substitution>
can only appear as the first element. Let's enforce that. Note I do
not remove these from the loop, to make the change easier to follow
(such a change will come later).
3) Given that, there's no need to special case 'St' outside of the
loop, handle it with the other 'S' elements.
4) There's no need to reset 'EndsWithTemplateArgs' after each
non-template-arg component. Rather, always clear it and then set it
in the template-args case.
5) An template-args cannot immediately follow a template-args.
6) The parsing of a CDtor name with ABITags would attach the tags to
the NestedName node, rather than the CDTor node. This is different to
how ABITags are attached to an unscopedName. Make it consistent.
7) We remain with only CDTor and UnscopedName requireing construction
of a NestedName, so let's drop the PushComponent lambda.
8) Add some tests to catch the new rejected manglings.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D118132
We were dropping the [gs] modifier by parsing it in parseExpr, but not
forwarding it on to parseUnresolvedName. This is the straightforwards
fix to forward that flag -- parseExpr must see past it.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D118504
The StdQualifiedName node class is used for names exactly in the std
namespace. It is not used for nested names that descend further --
those use a NestedName with NameType("std") as the scope.
Representing the compression scheme in the node graph is layer
breaking. We can use the same structure for those exactly in std too,
and reduce code size a bit.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D118249
While prepending lines to the copied source files is functional, it
disturbs the line numbering between the original and the copy. That
makes development more awkward than necessary, as it is the copy that
generally gets compiled first and emits compiler errors.
This uses sed to alter the first two lines, and also emits better
emacs mode setting, getting both C++ mode and read-only mode.
While here, also update and clarify documentation.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D118135
Code generating the special substitutions in std is a switch statement
with each case block containing the same conststruction template. It
is more efficient to commonize that after the switch, having
determined which SubKind to create. Also, let's sort the cases.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D118131
There's some unnecessary code duplication in the parser. This
refactors that and deploys boolean variables to avoid the duplication.
These also happen to help adding module demangling (with an updated
mangling scheme).
1a) The grammar requires some lookahead concerning <template-args>. We
may discover an <unscoped-name> is actually <unscoped-template-name>
<template-args>. (When <unscoped-name> was a substitution, there must
be a following <template-args>.) Refactor parseName to only have one
code path looking for the 'I' indicating <template-args>.
1b) While there I altered the control flow to hold the result in a
variable, rather than tail call. Made it easier to debug (and of
course an optimizer will DTRT here anyway).
2a) An <unscoped-name> can have an St or StL prefix. No need for
completely separate code paths handling the following unqualified-name
though.
2b) Also no need to look for both 'St' and 'StL' separately. Look for
'St' and then conditionally swallow an 'L'.
3) We get a similar issue as #1a when parsing a typeName. Here I just
change the control flow slightly to bring the 'break' out to the end
of the 'S' block and embed the early return inside an if. That's more
in keeping with the code style.
4) Although NFC, there's a new testcase as that's not covered by the
existing demangler tests and is significant in the #1a case above.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D117879
To try and avoid undesired changes to the non-canonical demangler
sources, change the cp-to-llvm script to (a) write-protect the target
files and (b) prepend 'do not edit' comments that are significant to
emacs[*], and hopefully humans.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D118008
Recent commits changed llvm/include/llvm/Demangle without also
changing libcxxabi/src/Demangle, which is the canonical source
location. This resyncs those commits to the libcxxabi directory.
Commits:
* 1f9e18b656
* f53d359816
* 065044c443
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D117990.diff
Some precursor work to adding module demangling.
* some mismatched comment and code in the demangler
* a const fn was not marked thusly
* we use std::islower. A direct range check is smaller code (no function call),
and we know we're in ASCII-land and later in that same function make the same
assumption about upper-case contiguity. Heck, maybe just drop the switch's
precondition and rely on the optimizer to do its thing?
* the directory is cloned in two places, which had gotten out of sync.
Differential Revision: https://reviews.llvm.org/D117800
I didn't split the calendar bits more than this because there was little
benefit to doing it, and I know our calendar support is incomplete.
Whoever picks up the missing calendar bits can organize these headers
at their leisure.
Differential Revision: https://reviews.llvm.org/D116965
This is the 5th of 5 changes to overhaul cxa_guard.
See D108343 for what the final result will be.
Depends on D115368
Reviewed By: ldionne, #libc_abi
Differential Revision: https://reviews.llvm.org/D115369
Currently, the `InitByte...` classes inherit from `GuardObject` so they can
access the `base_address`, `init_byte_address` and `thread_id_address`. Then,
since `GuardObject` needs to call `acquire`/`release`/`abort_init_byte`, it uses
the curiously recurring template pattern (CRTP). This is rather messy.
Instead, we'll have `GuardObject` contain an instance of `InitByte`, and pass it
the addresses it needs in the constructor. `GuardObject` doesn't need the
addresses anyways, so it makes more sense for `InitByte` to keep them instead of
`GuardObject`. Then, `GuardObject` can call `acquire`/`release`/`abort` as one
of `InitByte`'s member functions.
Organizing things this way not only gets rid of the use of the CRTP, but also
improves separation of concerns a bit since the `InitByte` classes are no longer
indirectly responsible for things because of their inheritance from
`GuardObject`. This means we no longer have strange things like calling
`InitByteFutex.cxa_guard_acquire`, instead we call
`GuardObject<InitByteFutex>.cxa_guard_acquire`.
This is the 4th of 5 changes to overhaul cxa_guard.
See D108343 for what the final result will be.
Depends on D115367
Reviewed By: ldionne, #libc_abi
Differential Revision: https://reviews.llvm.org/D115368
Right now, GuardObject is in charge of both reading and writing to the guard
byte, and co-ordinating with the InitByte... classes. In order to improve
separation of concerns, create a separate class responsible for managing the
guard byte and use that inside GuardObject.
This is the 3rd of 5 changes to overhaul cxa_guard.
See D108343 for what the final result will be.
Depends on D110088
Reviewed By: ldionne, #libc_abi
Differential Revision: https://reviews.llvm.org/D115367
By relying on PlatformSupportsThreadID, InitByteGlobalMutex disregards
the GetThreadID template argument, rendering it useless.
This is the 2nd of 5 changes to overhaul cxa_guard.
See D108343 for what the final result will be.
Depends on D109539
Reviewed By: ldionne, #libc_abi
Differential Revision: https://reviews.llvm.org/D110088
This will make the naming more consistent with what it's called in the
rest of the file.
This is the 1st of 5 changes to overhaul cxa_guard.
See D108343 for what the final result will be.
Reviewed By: ldionne, #libc_abi
Differential Revision: https://reviews.llvm.org/D109539
There's a lot of history behind this, so here's a summary:
1. I stopped forcing -fPIC when building the runtimes in 30f305efe2,
before the LLVM 9 release back in 2019.
2. Someone complained that libc++.a couldn't be used in shared libraries
built without -fPIC (http://llvm.org/PR43604) since the LLVM 9 release.
This had been caused by my removal of -fPIC when building libc++.a in (1).
3. I suggested two ways of fixing the issue, the first being to force
-fPIC back unconditionally (http://llvm.org/D104328), and the second
being to specify that option explicitly when building the LLVM release
(http://llvm.org/D104327). We converged on the first solution.
4. I landed D104328, which forced building the runtimes with -fPIC.
This was included in the LLVM 13.0 release.
5. People complained about that and requested that we be able to
customize this setting (basically we should have done the second
solution).
This patch makes it such that the LLVM release script will specifically
ask for building with -fPIC using CMAKE_POSITION_INDEPENDENT_CODE,
however by default the runtimes will not force that option onto users.
This patch has the unintended effect that Clang and the LLVM libraries
(not only the runtime ones like libc++) will also be built with -fPIC
in the release. It would be better if we could specify that -fPIC is to
be used only when building the runtimes, however this is left as a
future improvement. The release should probably be using a bootstrapping
build and passing those options to the stage that builds the runtimes
only, see https://reviews.llvm.org/D112748 for that change.
Differential Revision: https://reviews.llvm.org/D110261
When unwind step reaches the end of the stack that means the force unwind should notify the stop function.
This is not an error, it could mean just the thread is cleaned up completely.
Reviewed By: #libunwind, mstorsjo
Differential Revision: https://reviews.llvm.org/D109856
We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste stuff.
This cleans up all the existing files so as to stop the spreading
as people copy-paste headers around.
On Armv6-M the branch may not able to reach the _Unwind_Resume function because it's relocation(R_ARM_THM_JUMP11) is in -2048, 2047 range only.
Reviewed By: chill, stuij, lenary
Differential Revision: https://reviews.llvm.org/D113181
On Armv6-M the branch may not able to reach the _Unwind_Resume function because it's relocation(R_ARM_THM_JUMP11) is in -2048, 2047 range only.
Reviewed By: chill, stuij, lenary
Differential Revision: https://reviews.llvm.org/D113181
This is relanding commit da1d1a0869 .
This patch additionally addresses failures found in buildbots & post review comments.
ARM EHABI[1] specifies the __cxa_end_cleanup to be called after cleanup.
It will call the UnwindResume.
__cxa_begin_cleanup will be called from libcxxabi while __cxa_end_cleanup is never called.
This will trigger a termination when a foreign exception is processed while UnwindResume is called
because the global state will be wrong due to the missing __cxa_end_cleanup call.
Additional test here: D109856
[1] https://github.com/ARM-software/abi-aa/blob/main/ehabi32/ehabi32.rst#941compiler-helper-functions
Reviewed By: logan
Differential Revision: https://reviews.llvm.org/D111703
This is relanding commit da1d1a0869 .
This patch additionally addresses failures found in buildbots & post review comments.
ARM EHABI[1] specifies the __cxa_end_cleanup to be called after cleanup.
It will call the UnwindResume.
__cxa_begin_cleanup will be called from libcxxabi while __cxa_end_cleanup is never called.
This will trigger a termination when a foreign exception is processed while UnwindResume is called
because the global state will be wrong due to the missing __cxa_end_cleanup call.
Additional test here: D109856
[1] https://github.com/ARM-software/abi-aa/blob/main/ehabi32/ehabi32.rst#941compiler-helper-functions
Reviewed By: logan
Differential Revision: https://reviews.llvm.org/D111703
There's a lot of duplicated calls to find various compiler-rt libraries
from build of runtime libraries like libunwind, libc++, libc++abi and
compiler-rt. The compiler-rt helper module already implemented caching
for results avoid repeated Clang invocations.
This change moves the compiler-rt implementation into a shared location
and reuses it from other runtimes to reduce duplication and speed up
the build.
Differential Revision: https://reviews.llvm.org/D88458
ARM EHABI[1] specifies the __cxa_end_cleanup to be called after cleanup.
It will call the UnwindResume.
__cxa_begin_cleanup will be called from libcxxabi while __cxa_end_cleanup is never called.
This will trigger a termination when a foreign exception is processed while UnwindResume is called
because the global state will be wrong due to the missing __cxa_end_cleanup call.
Additional test here: D109856
[1] https://github.com/ARM-software/abi-aa/blob/main/ehabi32/ehabi32.rst#941compiler-helper-functions
Reviewed By: logan
Differential Revision: https://reviews.llvm.org/D111703
Nathan Sidwell