Commit Graph

1247 Commits

Author SHA1 Message Date
Martin Storsjö ebde6fc23b [libcxxabi] Fix cmake order dependency wrt dllexporting
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
2022-03-07 15:36:04 -05:00
Nathan Sidwell 64221645a8 [demangler] Make OutputBuffer non-copyable
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
2022-03-04 04:43:37 -08:00
Nikolas Klauser bd44174547 [libc++] Use -I instead of -isystem to include headers in the test suite
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
2022-03-03 13:19:47 +01:00
Louis Dionne 3ee0cec88e [runtimes] Remove FOO_TARGET_TRIPLE, FOO_SYSROOT and FOO_GCC_TOOLCHAIN
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
2022-03-01 08:39:42 -05:00
Louis Dionne 368faacac7 [libc++] Revert "Protect users from relying on detail headers" & related changes
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
2022-03-01 08:20:24 -05:00
Nathan Sidwell 75db1795e4 [demangler] Add co_await demangling
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
2022-03-01 04:49:19 -08:00
Nathan Sidwell 7f89fa32e8 [demangler][NFC] Tabularize operator name parsing
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
2022-03-01 04:44:56 -08:00
Nathan Sidwell 024495e626 [demangler] Improve buffer hysteresis
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
2022-03-01 04:37:24 -08:00
Nathan Sidwell e5c98e22fb [demangler] Simplify SwapAndRestore
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
2022-03-01 04:37:24 -08:00
Louis Dionne 6dfdf79b8c [libc++abi] Install the libc++abi headers from libc++abi
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
2022-02-28 17:22:53 -05:00
Christopher Di Bella 5aaefa510e [libcxx][modules] protects users from relying on detail headers
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
2022-02-26 09:00:25 +00:00
Nathan Sidwell 12c4e65a76 [demangler][NFC] Reformatting
The linter complains about the formatting in subsequent changes.
Fixing that now.

Reviewed By: iains

Differential Revision: https://reviews.llvm.org/D120117
2022-02-18 08:56:01 -08:00
Louis Dionne 259c58d7d8 [libc++abi] Bump the libc++abi version and add it to the post-release list
Differential Revision: https://reviews.llvm.org/D119947
2022-02-16 16:27:25 -05:00
Michał Górny 5244ef0faf [libcxxabi] [test] Depend on unwind only if available
When building libcxxabi via LLVM_ENABLE_RUNTIMES=libcxxabi the CMake
invocation fails because of missing "unwind" target.  However,
if the extraneous dependency is removed, the library builds just fine
against installed libunwind and tests work fine.  To fix this,
add the dependency only if the target actually exists.

Differential Revision: https://reviews.llvm.org/D119538
2022-02-16 19:30:25 +01:00
Louis Dionne 2e3bb910e3 [runtimes] Move warning messages for FOO_SYSROOT & friends above their default value
Otherwise, the warnings always trigger.
2022-02-16 12:00:34 -05:00
Nathan Sidwell fbf7bbcb83 [demangler] Fix build breakage
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/
2022-02-16 08:57:37 -08:00
Louis Dionne 641a141da1 [runtimes] Deprecate FOO_SYSROOT & friends
As suggested in https://reviews.llvm.org/D112155.

Differential Revision: https://reviews.llvm.org/D119836
2022-02-16 09:44:08 -05:00
Nathan Sidwell 6244730e29 [demangler] Reorder parseNestedName loop
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
2022-02-16 04:30:47 -08:00
Nikolas Klauser 2e2f3158c6 [libc++] Granularize algorithm includes
Reviewed By: Mordante, ldionne, Quuxplusone, #libc, #libc_abi

Spies: #libc_vendors, libcxx-commits, miyuki

Differential Revision: https://reviews.llvm.org/D119667
2022-02-16 04:12:22 +01:00
Arthur O'Dwyer 05337a756c [libc++] Rename *SAFE_STATIC to *CONSTINIT, and normalize its uses.
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
2022-02-15 10:39:41 -05:00
Louis Dionne 8c06061372 [libc++abi] Add a from-scratch testing config for Apple backdeployment
We added one for libc++ recently, and this patch adds one for libc++abi.
Also, as a fly-by fix, include older libunwind dylibs in the testing of
libc++ and libc++abi, which fixes some issues related to running
back-deployment tests on newer systems.

Differential Revision: https://reviews.llvm.org/D119466
2022-02-14 15:36:50 -05:00
Nathan Sidwell 880e87580a [demangler][NFC] Tweak legacy uuidof handling
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
2022-02-14 04:00:49 -08:00
Nathan Sidwell 995c4f3068 [demangler] Fix buffer growth
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
2022-02-14 03:59:31 -08:00
Nathan Sidwell fbded4f42d [demangler] Adjust unqualified name parsing
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
2022-02-11 04:22:06 -08:00
Nathan Sidwell 9d283634f7 [demangler] Fix new/delete demangling
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
2022-02-10 04:33:02 -08:00
Louis Dionne 6f17768e11 [runtimes] Remove support for standalone builds
Standalone build have been deprecated for some time now, so this
commit removes support for those builds entirely from libc++, libc++abi
and libunwind.

This, along with the removal of other legacy ways to build, will allow
for major build system simplifications.

Differential Revision: https://reviews.llvm.org/D119255
2022-02-09 08:55:31 -05:00
Nathan Sidwell f0ef708dc1 [demangler][NFC] Utility header cleanups
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
2022-02-08 07:25:02 -08:00
Nathan Sidwell 28669bd091 [demangler] Improve ->* & .* demangling
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
2022-02-08 06:28:26 -08:00
Nathan Sidwell ad46cf14d4 [demangler] Stricter NestedName parsing
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
2022-02-07 08:20:45 -08:00
Nathan Sidwell 8d38273a3d [demangler] Fix unresolvedname demangling
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
2022-02-07 07:49:30 -08:00
Nathan Sidwell 704b21cb4f [demangler] Remove StdQualifiedName
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
2022-02-07 07:49:30 -08:00
Nathan Sidwell fa7834a554 [demangler] Preserve line numbering in copied demangler sources
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
2022-02-01 05:30:24 -08:00
Nathan Sidwell 4e5fce5848 [demangler] refactor SpecialSubKind
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
2022-01-26 04:59:25 -08:00
Nathan Sidwell 52c7faeae8 [demangler] improve test harness
The demangler test harness is a little unclear.  The failed demangling
message always causes me to think about 'reality', changing to a
simple 'Found' seems clearer.

The expected-to-fail tests abort as soon as one passes, rather than
continue, and then abort if any passed.  This changes that loop to
fail at the end, in a similar manner to the expected-to-work loop.

Reviewed By: ChuanqiXu

Differential Revision: https://reviews.llvm.org/D118130
2022-01-26 04:59:25 -08:00
Nathan Sidwell 6184e565ad [demangler][NFC] Refactor some parsing
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
2022-01-24 05:28:38 -08:00
Nathan Sidwell 897d1bb659 [demangler] write-protect non-canonical source
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
2022-01-24 05:28:38 -08:00
Nathan Sidwell 38ffea9b4c [demangler] Resync demangler sources
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
2022-01-24 05:28:38 -08:00
Nathan Sidwell 8105e404f1 [demangler][NFC] Small cleanups and sync
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
2022-01-20 11:47:06 -08:00
John Ericson df31ff1b29 [cmake] Make include(GNUInstallDirs) always below project(..)
Its defaulting logic must go after `project(..)` to work correctly,  but `project(..)` is often in a standalone condition making this
awkward, since the rest of the condition code may also need GNUInstallDirs.

The good thing is there are the various standalone booleans, which I had missed before. This makes splitting the conditional blocks less awkward.

Reviewed By: arichardson, phosek, beanz, ldionne, #libunwind, #libc, #libc_abi

Differential Revision: https://reviews.llvm.org/D117639
2022-01-20 18:59:17 +00:00
John Ericson 429a717ea5 [cmake] Move HandleOutOfTreeLLVM to common cmake utils
This is better than libunwind and libcxxabi fishing it out of libcxx's
module directory.

It is done in prepartion for a better version of D117537 which deduplicates
CMake logic instead of just renaming to avoid a name clash.

Reviewed By: phosek, #libunwind, #libc_abi, Ericson2314

Differential Revision: https://reviews.llvm.org/D117617
2022-01-19 22:05:23 +00:00
John Ericson f16a4a034a [libcxx][libcxxabi][libunwind][cmake] Use `GNUInstallDirs` to support custom installation dirs
I am breaking apart D99484 so the cause of build failures is easier to
understand.

Differential Revision: https://reviews.llvm.org/D117417
2022-01-18 06:44:57 +00:00
John Ericson da77db58d7 Revert "[cmake] Use `GNUInstallDirs` to support custom installation dirs."
https://lab.llvm.org/buildbot/#/builders/46/builds/21146 Still have
this odd error, not sure how to reproduce, so I will just try breaking
up my patch.

This reverts commit 4a678f8072.
2022-01-16 05:48:30 +00:00
John Ericson 4a678f8072 [cmake] Use `GNUInstallDirs` to support custom installation dirs.
This is the original patch in my GNUInstallDirs series, now last to merge as the final piece!

It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up

 - Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested.

 - Converting all the packages, not just LLVM, effecting many more projects than LLVM itself.

I figured it was time to make a new revision.

I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful.

---

As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`.

These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder.

Reviewed By: #libunwind, #libc, #libc_abi, compnerd

Differential Revision: https://reviews.llvm.org/D99484
2022-01-16 05:33:07 +00:00
John Ericson 6e52bfe09d Revert "[cmake] Use `GNUInstallDirs` to support custom installation dirs."
Sorry for the disruption, I will try again later.

This reverts commit efeb501970.
2022-01-15 07:35:02 +00:00
John Ericson efeb501970 [cmake] Use `GNUInstallDirs` to support custom installation dirs.
This is the original patch in my GNUInstallDirs series, now last to merge as the final piece!

It arose as a new draft of D28234. I initially did the unorthodox thing of pushing to that when I wasn't the original author, but since I ended up

 - Using `GNUInstallDirs`, rather than mimicking it, as the original author was hesitant to do but others requested.

 - Converting all the packages, not just LLVM, effecting many more projects than LLVM itself.

I figured it was time to make a new revision.

I have used this patch series (and many back-ports) as the basis of https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS), which was merged last spring (2021). It looked like people were generally on board in D28234, but I make note of this here in case extra motivation is useful.

---

As pointed out in the original issue, a central tension is that LLVM already has some partial support for these sorts of things. Variables like `COMPILER_RT_INSTALL_PATH` have already been dealt with. Variables like `LLVM_LIBDIR_SUFFIX` however, will require further work, so that we may use `CMAKE_INSTALL_LIBDIR`.

These remaining items will be addressed in further patches. What is here is now rote and so we should get it out of the way before dealing more intricately with the remainder.

Reviewed By: #libunwind, #libc, #libc_abi, compnerd

Differential Revision: https://reviews.llvm.org/D99484
2022-01-15 01:08:35 +00:00
Muiez Ahmed a1da73961d [SystemZ][z/OS] ASCII/EBCDIC support with no coexistence
The aim of this patch is to break up the larger patch (https://reviews.llvm.org/D111323) to be more upstream friendly. In particular, this patch adds the char encoding sensitive changes but does not use inline namespaces as before. The use of namespaces to build both versions of the library, and localization of error messages will follow in a subsequent patch.

Differential Revision: https://reviews.llvm.org/D114813
2022-01-14 11:37:09 -05:00
Louis Dionne 5726e55981 [libc++] Modularize <chrono>
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
2022-01-14 09:55:29 -05:00
Daniel McIntosh f011a53c14 [libcxxabi] Added convenience classes to cxa_guard
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
2022-01-12 17:31:36 -05:00
Daniel McIntosh 29be7c9c4f [libcxxabi] Re-organized inheritance structure to remove CRTP in cxa_guard
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
2022-01-12 17:31:08 -05:00
Daniel McIntosh 847ea76219 [libcxxabi] Pulled guard byte code out of GuardObject
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
2022-01-12 17:30:39 -05:00
Daniel McIntosh 3601ee6cfd [libcxxabi] Make InitByteGlobalMutex check GetThreadID instead of PlatformThreadID
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
2022-01-12 17:30:10 -05:00
Daniel McIntosh e42eeb88d7 [NFC][libcxxabi] Rename GlobalLock to GlobalMutex
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
2022-01-12 17:29:17 -05:00
John Ericson 0a8d15ad55 [libc++][libc++abi][libunwind] Dedup install path var definitions
In D116873 I did this for libunwind prior to defining a new install path
variable. But I think the change is good on its own, and libc++{,abi}
could also use it.

libc++ needed the base header var defined above the conditional part to
use it for the prefi+ed headers in the non-target-specific case. For
consistency, I therefore put the unconditional ones above for all 3
libs, which is why I touched the libunwind code (seeing that it had the
core change already)

Reviewed By: phosek, #libunwind, #libc, #libc_abi, ldionne

Differential Revision: https://reviews.llvm.org/D116988
2022-01-11 18:24:50 +00:00
Ben Wagner fb1582f6c5 [libc++] Disable coverage with sanitize-coverage=0
When building libcxx, libcxxabi, and libunwind the build environment may
specify any number of sanitizers. For some build feature tests these
sanitizers must be disabled to prevent spurious linking errors. With
-fsanitize= this is straight forward with -fno-sanitize=all. With
-fsanitize-coverage= there is no -fno-sanitize-coverage=all, but there
is the equivalent undocumented but tested -fsanitize-coverage=0.

The current build rules fail to disable 'trace-pc-guard'. By disabling
all sanitize-coverage flags, including 'trace-pc-guard', possible
spurious linker errors are prevented. In particular, this allows libcxx,
libcxxabi, and libunwind to be built with HonggFuzz.

CMAKE_REQUIRED_FLAGS is extra compile flags when running CMake build
configuration steps (like check_cxx_compiler_flag). It does not affect
the compile flags for the actual build of the project (unless of course
these flags change whether or not a given source compiles and links or
not). So libcxx, libcxxabi, and libunwind will still be built with any
specified sanitize-coverage as before. The build configuration steps
(which are mostly checking to see if certain compiler flags are
available) will not try to compile and link "int main() { return 0;}"
(or other specified source) with sanitize-coverage (which can fail to
link at this stage in building, since the final compile flags required
are yet to be determined).

The change to LIBFUZZER_CFLAGS was done to keep it consistent with the
obvious intention of disabling all sanitize-coverage. This appears to
be intentional, preventing the fuzzer driver itself from showing up in
any coverage calculations.

Reviewed By: #libunwind, #libc, #libc_abi, ldionne, phosek

Differential Revision: https://reviews.llvm.org/D116050
2022-01-07 17:53:21 -08:00
John Ericson 949bbd0a68 [CMake] Use `LLVM_COMMON_CMAKE_UTILS` in runtimes just for clarity
In D116472 we created conditionally defined variables for the tools to
unbreak the legacy build where they are in `llvm/tools`.

The runtimes are not tools, so that flexibility doesn't matter. Still,
it might be nice to define (unconditionally) and use the variable for
the runtimes simply to make the code a bit clearer and document what is
going on.

Also, consistently put project dirs at the beginning, not end of `CMAKE_MODULE_PATH`. This ensures they will properly shadow similarly named stuff that happens to be later on the path.

Reviewed By: mstorsjo, #libunwind, #libc, #libc_abi, ldionne

Differential Revision: https://reviews.llvm.org/D116477
2022-01-03 20:55:44 +00:00
Martin Storsjö c1a14a5c3e [libcxx] Use LIBCXX_EXECUTOR in new test configs
This allows cross-testing (by setting LIBCXX_EXECUTOR to point
to ssh.py) without making an entirely new test config file.

Implicitly, this also fixes quoting of the python executable name
(which is quoted in test/CMakeLists.txt).

Differential Revision: https://reviews.llvm.org/D115398
2021-12-22 00:43:28 +02:00
Louis Dionne 7c1d4c2e77 [libc++abi][NFC] Fix comment 2021-12-13 10:29:29 -05:00
Ties Stuij 69faae2376 [ARM][libcxxabi] Add PACBTI-M support to libcxxabi
This change consists of just adding 'BTI' to the prologue of Arm assembly
functions, which is just the one: __cxa_end_cleanup

This patch is part of a series that adds support for the PACBTI-M extension of
the Armv8.1-M architecture, as detailed here:

https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-1-m-pointer-authentication-and-branch-target-identification-extension

The PACBTI-M specification can be found in the Armv8-M Architecture Reference
Manual:

https://developer.arm.com/documentation/ddi0553/latest

The following people contributed to this patch:

- Mikhail Maltsev

Reviewed By: lenary, danielkiss

Differential Revision: https://reviews.llvm.org/D112432
2021-12-10 09:53:40 +00:00
Xing Xue bc7f0fb5ea [libc++abi][AIX] Add 2 LIT tests for the AIX unwinder
Summary:
This patch creates sub-directory libcxxabi/test/vendor/ibm and adds 2 LIT test cases for the AIX EH under the directory. One tests the restoration of the condition register and the other tests the restoration of vector registers. Both are saved on the stack by the function prologue.

Reviewed by: compnerd, libc++abi

Differential Revision: https://reviews.llvm.org/D114445
2021-12-09 16:43:32 -05:00
Louis Dionne a6e5563dfa [libc++][release] Do not force building the runtimes with -fPIC
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
2021-12-08 11:34:35 -05:00
Louis Dionne dc1244dc4e [runtimes] Move WARNING to FATAL_ERROR for folks using FOO_BUILD_32_BITS 2021-12-01 12:57:30 -05:00
Louis Dionne fa1c077b41 [runtimes] Remove support for GCC-style 32 bit multilib builds
This patch removes the ability to build the runtimes in the 32 bit
multilib configuration, i.e. using -m32. Instead of doing this, one
should cross-compile the runtimes for the appropriate target triple,
like we do for all other triples.

As it stands, -m32 has several issues, which all seem to be related to
the fact that it's not well supported by the operating systems that
libc++ support. The simplest path towards fixing this is to remove
support for the configuration, which is also the best course of action
if there is little interest for keeping that configuration. If there
is a desire to keep this configuration around, we'll need to do some
work to figure out the underlying issues and fix them.

Differential Revision: https://reviews.llvm.org/D114473
2021-12-01 12:57:01 -05:00
Daniel Kiss 632acec737 [libunwind][ARM] Handle end of stack during unwind
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
2021-11-26 13:26:49 +01:00
Arthur O'Dwyer 401b76fdf2 [libc++] [test] Eliminate libcpp-no-noexcept-function-type and libcpp-no-structured-bindings.
At this point, every supported compiler that claims a -std=c++17 mode
should also support these features.

Differential Revision: https://reviews.llvm.org/D113436
2021-11-20 11:44:57 -05:00
Louis Dionne eb8650a757 [runtimes][NFC] Remove filenames at the top of the license notice
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.
2021-11-17 16:30:52 -05:00
Louis Dionne ea23cc7120 [libc++abi] Don't re-define _LIBCPP_HAS_NO_THREADS in single-threaded mode
Libc++ already defines the macro inside its __config_site header, so
libc++abi doesn't need to do it. Doing it just leads to -Wmacro-redefined
warnings when building libc++abi.
2021-11-17 10:59:39 -05:00
David Tenty 2b416b4647 [libcxx][CI][AIX] Switch to LLVM_ENABLE_RUNTIMES
and to the new `runtimes` top level CMakeLists.txt since the old path is now deprecated. This requires a slight adjustment of the libcxxabi CMake, since there are required macro definitions we previously got via the `llvm/CMakeList.txt` path.

Reviewed By: ldionne, #libc, #libc_abi

Differential Revision: https://reviews.llvm.org/D113403
2021-11-09 16:04:10 -05:00
Daniel Kiss c5c4bac6c0 Reland "[libcxxabi][ARM] Make CXX_end_cleanup compatible with Armv6-M"
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
2021-11-09 12:53:53 +01:00
Vladimir Vereschaka c0d22dd0e7 Revert "[libcxxabi][ARM] Make CXX_end_cleanup compatible with Armv6-M"
This reverts commit 3255578ee1.

Failed buildbot's Armv7 builds:
https://lab.llvm.org/buildbot/#/builders/60/builds/5303
2021-11-05 21:01:03 -07:00
Daniel McIntosh 795ff77840 [libcxxabi] Fix NO_THREADS version of test_exception_storage.pass.cpp
`thread_code` returns param, which for NO_THREADS is going to be
`&thread_globals`. Thus, the return value will never be null. The test
was probably meant to check if `*thread_code(&thread_globals) == 0`.
However, to avoid the extra cast, and to bring the NO_THREADS version
more in line with the regular version of the test, this changes it to
check if thread_globals == 0 directly.

Reviewed By: ldionne, #libc_abi

Differential Revision: https://reviews.llvm.org/D113048
2021-11-04 19:30:21 -04:00
Daniel Kiss 3255578ee1 [libcxxabi][ARM] Make CXX_end_cleanup compatible with Armv6-M
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
2021-11-04 16:29:39 +01:00
Louis Dionne a55632a069 [libc++] Temporarily mark tests as UNSUPPORTED to get the CI green
After recent changes to the Docker image, all hell broke loose and the
CI started failing. This patch marks a few tests as unsupported until
we can figure out what the issues are and fix them.

In the future, it would be ideal if the nodes could pick up the Dockerfile
present in the revision being tested, which would allow us to test changes
to the Dockerfile in the CI, like we do for all other code changes.

Differential Revision: https://reviews.llvm.org/D112737
2021-10-28 16:30:42 -04:00
Daniel Kiss d8075e8781 Reland "[ARM] __cxa_end_cleanup should be called instead of _UnwindResume."
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
2021-10-28 21:45:09 +02:00
Daniel Kiss 66e03db814 Revert "Reland "[ARM] __cxa_end_cleanup should be called instead of _UnwindResume.""
This reverts commit b6420e575f.
2021-10-28 17:24:53 +02:00
Daniel Kiss b6420e575f Reland "[ARM] __cxa_end_cleanup should be called instead of _UnwindResume."
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
2021-10-28 16:49:19 +02:00
Petr Hosek 22acda48ff [CMake] Cache the compiler-rt library search results
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
2021-10-27 17:53:03 -07:00
Daniel Kiss 894ddba1c9 Revert "[ARM] __cxa_end_cleanup should be called instead of _UnwindResume."
This reverts commit da1d1a0869.
2021-10-27 14:29:35 +02:00
Daniel Kiss da1d1a0869 [ARM] __cxa_end_cleanup should be called instead of _UnwindResume.
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
2021-10-27 10:40:00 +02:00
Luís Ferreira 2d77b272a8 [Demangle] Add prepend functionality to OutputString
Implement the functionallity of prepend, required by D demangler.
Please read discussion https://reviews.llvm.org/D111414 for context.
See also https://reviews.llvm.org/D111947 .

Reviewed By: dblaikie, Geod24

Differential Revision: https://reviews.llvm.org/D111948
2021-10-26 16:24:25 -07:00
David Blaikie 85bf221f20 Fix for OutputStream->OutputBuffer rename 2021-10-21 20:14:04 -07:00
Vitaly Buka 34c97d5ae3 [libcxxabi] Fix build after D111947 2021-10-21 18:35:12 -07:00
Luís Ferreira 2e97236aac [Demangle] Rename OutputStream to OutputString
This patch is a refactor to implement prepend afterwards. Since this changes a lot of files and to conform with guidelines, I will separate this from the implementation of prepend. Related to the discussion in https://reviews.llvm.org/D111414 , so please read it for more context.

Reviewed By: #libc_abi, dblaikie, ldionne

Differential Revision: https://reviews.llvm.org/D111947
2021-10-21 17:34:57 -07:00
Petr Hosek ba4920e98e Revert "[CMake] Cache the compiler-rt library search results"
This reverts commit 0eed292fba, there
are compiler-rt build failures that appear to have been introduced
by this change.
2021-10-21 10:32:01 -07:00
Louis Dionne 72117f2ffe [runtimes] Properly handle the sysroot/triple/gcc-toolchain
In 395271a, I simplified how we handled the target triple for the
runtimes. However, in doing so, we stopped considering the default
in CMAKE_CXX_COMPILER_TARGET, so we'd use the LLVM_DEFAULT_TARGET_TRIPLE
(which is the host triple) even if CMAKE_CXX_COMPILER_TARGET was specified.
This commit fixes that problem and also refactors the code so that it's
easy to see what the default value is.

The fact that nobody seems to have been broken by this makes me think
that perhaps nobody is using CMAKE_CXX_COMPILER_TARGET to specify the
triple -- but it should still work.

Differential Revision: https://reviews.llvm.org/D111672
2021-10-21 10:06:11 -04:00
Louis Dionne ff5050a3a4 [libc++abi] Guard include of <unistd.h> behind __has_include
This doesn't change anything on platforms that have <unistd.h>, but
it will allow this file to compile on platforms that do not.
2021-10-20 17:37:19 -04:00
Petr Hosek 0eed292fba [CMake] Cache the compiler-rt library search results
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
2021-10-18 14:44:07 -07:00
David Tenty 228b3b729d [libc++][AIX] Add scripts and config for building with the libcxx CI infrastructure
This initial change adds the AIX configuration to run-buildbot, an AIX
CMake cache file, and appropriate compiler and linker flags for testing
AIX to the lit "from scratch" configuration files. Either of the 32-bit or 64-bit configurations
can be built by setting `OBJECT_MODE` in the build environment (as is
typical for AIX).

Reviewed By: ldionne, #libc, #libc_abi

Differential Revision: https://reviews.llvm.org/D111244
2021-10-14 14:31:10 -04:00
Louis Dionne d1e0f02e0b [libc++abi][ci] Add a from-scratch config for libc++abi on Apple/system
I came across an issue where since we build the library for Apple with
the install name directory being /usr/lib, which means that if we don't
run the tests with DYLD_LIBRARY_PATH, we'll end up loading the
system-provided libc++abi when running the tests. That wreaks havoc.

Instead of fixing it in the legacy config file, this commit introduces
an Apple libc++abi config file that does the right thing.

Differential Revision: https://reviews.llvm.org/D111279
2021-10-13 08:07:40 -04:00
Louis Dionne df3de7647e [libc++abi] Change LIBCXXABI_NO_TIMER to LIBCXXABI_USE_TIMER
Instead of always defining LIBCXXABI_NO_TIMER to run the tests, only
define LIBCXXABI_USE_TIMER when we want to enable the timer. This makes
the libc++abi testing configuration simpler.

As a fly-by fix, remove the unused LIBUNWIND_NO_TIMER macro from libunwind.

Differential Revision: https://reviews.llvm.org/D111667
2021-10-13 08:02:31 -04:00
Louis Dionne f6a74908a7 [runtimes] Add tests for vendor-specific properties
Vendors take libc++ and ship it in various ways. Some vendors might
ship it differently from what upstream LLVM does, i.e. the install
location might be different, some ABI properties might differ, etc.

In the past few years, I've come across several instances where
having a place to test some of these properties would have been
incredibly useful. I also just got bitten by the lack of tests
of that kind, so I'm adding some now.

The tests added by this commit for Apple platforms have numerous
TODOs that capture discrepancies between the upstream LLVM CMake
and the slightly-modified build we perform internally to produce
Apple's system libc++. In the future, the goal would be to upstream
all those differences so that it's possible to build a faithful
Apple system libc++ with the upstream LLVM sources only.

But this isn't only useful for Apple - this lays out the path for
any vendor being able to add their own checks (either upstream or
downstream) to libc++.

This is a re-application of 9892d1644f, which was reverted in 138dc27186
because it broke the build. The issue was that we didn't apply the required
changes to libunwind and our CI didn't notice it because we were not
running the libunwind tests. This has been fixed now, and we're running
the libunwind tests in CI now too.

Differential Revision: https://reviews.llvm.org/D110736
2021-10-07 15:46:20 -04:00
Louis Dionne 54a8a0d09a [runtimes] Allow FOO_TEST_CONFIG to be a relative path
That makes it possible to store that value in a CMake cache if needed.

Differential Revision: https://reviews.llvm.org/D110843
2021-10-05 19:45:50 -04:00
Louis Dionne d9346f5255 [libc++abi] Mark __cxa_new_handler with _LIBCPP_SAFE_STATIC
For consistency with the other handlers, and because requiring constant
initialization whenever we can is a good thing.

Differential Revision: https://reviews.llvm.org/D110866
2021-10-05 14:29:32 -04:00
Tomasz Miąsko c8c2b4629f [Demangle][Rust] Parse non-ASCII identifiers
Rust allows use of non-ASCII identifiers, which in Rust mangling scheme
are encoded using Punycode.

The encoding deviates from the standard by using an underscore as the
separator between ASCII part and a base-36 encoding of non-ASCII
characters (avoiding hypen-minus in the symbol name). Other than that,
the encoding follows the standard, and the decoder implemented here in
turn follows the one given in RFC 3492.

To avoid an extra intermediate memory allocation while decoding
Punycode, the interface of OutputStream is extended with an insert
method.

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D104366
2021-10-01 22:08:32 +02:00
Louis Dionne 6714e1ce3b [libc++abi][NFCI] Consistently group new_handler, unexpected_handler and terminate_handler
Previously, the definitions of __cxa_terminate_handler and __cxa_unexpected_handler
(and their set_xxx_handler functions) were grouped together, but the
definition of __cxa_new_handler wasn't. This commit simply moves those
to the same file to treat all handlers consistently.
2021-09-30 14:15:30 -04:00
Haowei Wu 138dc27186 Revert "[libc++][libc++abi] Add tests for vendor-specific properties"
This reverts commit 9892d1644f, which
causes clang test failures in libcxx tests.
2021-09-30 11:03:59 -07:00
Louis Dionne 9892d1644f [libc++][libc++abi] Add tests for vendor-specific properties
Vendors take libc++ and ship it in various ways. Some vendors might
ship it differently from what upstream LLVM does, i.e. the install
location might be different, some ABI properties might differ, etc.

In the past few years, I've come across several instances where
having a place to test some of these properties would have been
incredibly useful. I also just got bitten by the lack of tests
of that kind, so I'm adding some now.

The tests added by this commit for Apple platforms have numerous
TODOs that capture discrepancies between the upstream LLVM CMake
and the slightly-modified build we perform internally to produce
Apple's system libc++. In the future, the goal would be to upstream
all those differences so that it's possible to build a faithful
Apple system libc++ with the upstream LLVM sources only.

But this isn't only useful for Apple - this lays out the path for
any vendor being able to add their own checks (either upstream or
downstream) to libc++.

Differential Revision: https://reviews.llvm.org/D110736
2021-09-29 17:22:37 -04:00
Pengfei Wang 1873f3be78 [demangle] Support for ISO/IEC TS 18661 binary floating point type
Reviewed By: #libc_abi, ldionne

Differential Revision: https://reviews.llvm.org/D105278
2021-09-23 11:02:58 +08:00
Louis Dionne f8b1cc3657 [libc++abi] Remove unnecessary atomic_support.h header from libc++abi
The file was a duplicate of atomic_support.h in libc++. Since we now
require the libc++ sources in order to build libc++abi, it's OK to
remove this duplication.

Thanks to @chandlerc for noticing this.

Differential Revision: https://reviews.llvm.org/D110103
2021-09-21 19:55:21 -04:00
Nehal J Wani 1613ab8a4a [libcxx][libcxxabi] CMAKE_REQUIRED_FLAGS is a string, not a list
When `libcxx` or `libcxxabi` is built with `-DLLVM_USE_SANITIZER=MemoryWithOrigins`
**and** `-DLIBCXX[ABI]_USE_COMPILER_RT=ON`, all of the `LIBCXX[ABI]_SUPPORTS_*_FLAG`
checks fail, since the value of `CMAKE_REQUIRED_FLAGS` is not set correctly.

Bugzilla: https://bugs.llvm.org/show_bug.cgi?id=51774

Reviewed By: #libc, #libc_abi, compnerd, ldionne

Differential Revision: https://reviews.llvm.org/D109342
2021-09-16 18:26:29 +02:00
Zhouyi Zhou 6e91666e28 [libcxxabi] NFC: fix incorrect indentation of braces
Some functions in cxa_exception_storage.cpp have incorrect indentation
of braces; fix them.
Original patch by Zhouyi Zhou <zhouzhouyi@gmail.com>

Also, remove a line of commented-out (and no-longer-possible-to-compile)
code. That thread-safe-static initialization of `init` was replaced
with the call to pthread_once directly above it, back in 2012.

Differential Revision: https://reviews.llvm.org/D109408
2021-09-11 13:43:12 -05:00