Commit Graph

414 Commits

Author SHA1 Message Date
Louis Dionne 78669c4185 [libc++][tests] Use CMake provided paths for includes and libdir instead of hardcoding them
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
2022-03-16 12:35:06 -04: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
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
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
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
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 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
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 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
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 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
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
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 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
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
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
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
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
Louis Dionne d9eb6c7cf5 [libc++abi] Remove workarounds for missing -Wno-exceptions on older GCCs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97675 has now been resolved
in GCC 11, so we can remove those workarounds.

Differential Revision: https://reviews.llvm.org/D109188
2021-09-03 14:23:28 -04:00
Daniel Kiss f5b997e6b7 [Unwind] Harmonise exception class for EHABI spec.
EHABI defines the exception class as char[8] instead of uint64_t [1].
For ABI compatibility the ABI the definition needs to be updated.

[1] https://github.com/ARM-software/abi-aa/blob/main/ehabi32/ehabi32.rst#82language-independent-unwinding-types-and-functions

Reviewed By: manojgupta, MaskRay, #libunwind

Differential Revision: https://reviews.llvm.org/D109047
2021-09-02 11:31:03 +02:00
Louis Dionne 5425106e49 [libc++] Remove test-suite annotations for unsupported Clang versions
Differential Revision: https://reviews.llvm.org/D108471
2021-08-20 15:05:13 -04:00
Louis Dionne 3a244fcf29 [libc++] Remove more test-suite workarounds for unsupported GCC versions
Differential Revision: https://reviews.llvm.org/D108466
2021-08-20 13:26:43 -04:00
Mikhail Borisov f0fcd42495 [libc++abi] Fix possible infinite loop in itanium demangler
A libfuzzer run has discovered some inputs for which the demangler does
not terminate. When minimized, it looks like this: _Zcv1BIRT_EIS1_E

Deciphered:

_Z
cv    - conversion operator

      * result type
 1B   - "B"
 I    - template args begin
  R   - reference type              <.
   T_ - forward template reference   |  *
 E    - template args end            |  |
                                     |  |
      * parameter type               |  |
 I    - template args begin          |  |
  S1_ - substitution #1              * <'
 E    - template args end

The reason is: template-parameter refs in conversion operator result type
create forward-references, while substitutions are instantly resolved via
back-references. Together these can create a reference loop. It causes an
infinite loop in ReferenceType::collapse().

I see three possible ways to avoid these loops:

1. check if resolving a forward reference creates a loop and reject the
   invalid input (hard to traverse AST at this point)
2. check if a substitution contains a malicious forward reference and
   reject the invalid input (hard to traverse AST at this point;
   substitutions are quite common: may affect performance; hard to
   clearly detect loops at this point)
3. detect loops in ReferenceType::collapse() (cannot reject the input)

This patch implements (3) as seemingly the least-impact change. As a
side effect, such invalid input strings are not rejected and produce
garbage, however there are already similar guards in
`if (Printing) return;` checks.

Fixes https://llvm.org/PR51407

Differential Revision: https://reviews.llvm.org/D107712
2021-08-17 18:13:26 -04:00
Louis Dionne 6900df37d2 [libc++] Remove Lit annotations for unsupported GCC versions from the test suite
Since we officially don't support several older compilers now, we can
drop a lot of the markup in the test suite. This helps keep the test
suite simple and makes sure that UNSUPPORTED annotations don't rot.

This is the first patch of a series that will remove annotations for
compilers that are now unsupported.

Differential Revision: https://reviews.llvm.org/D107787
2021-08-12 13:30:47 -04:00
Daniel Kiss db126ae243 [Arm][Unwind][libc++abi] Add _Unwind_ForcedUnwind to EHABI.
_Unwind_ForcedUnwind is not mandated by the EHABI but for compatibilty
reasons adding so the interface to higher layers would be the same.
Dropping EHABI specific _Unwind_Stop_Fn definition since it is not defined by EHABI.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D89570
2021-08-11 10:15:53 +02:00
Louis Dionne 395271ad11 [runtimes] Simplify how we set the target triple
Instead of using TARGET_TRIPLE, which is always set to LLVM_DEFAULT_TARGET_TRIPLE,
use that variable directly to populate the various XXXX_TARGET_TRIPLE
variables in the runtimes.

This re-applies 77396bbc98 and 5099e01568, which were reverted in
850b57c5fb because they broke the build.

Differential Revision: https://reviews.llvm.org/D106009
2021-07-16 10:33:39 -04:00
Louis Dionne 851a335b1e [libc++] Add a job running GCC with C++11
This configuration is interesting because GCC has a different level of
strictness for some C++ rules. In particular, it implements the older
standards more stringently than Clang, which can help find places where
we are non-conforming (especially in the test suite).

Differential Revision: https://reviews.llvm.org/D105936
2021-07-15 22:13:03 -04:00
Louis Dionne 8fb47456a3 [libc++/abi] Fix broken Lit feature no-noexcept-function-type
The feature was always defined, which means that the two test cases
guarded by it were never run.

Differential Revision: https://reviews.llvm.org/D106062
2021-07-15 14:42:07 -04:00
Louis Dionne 0c3401c86e [runtimes] Serialize all Lit params instead of passing them to add_lit_testsuite
add_lit_testsuite() takes Lit parameters passed to it and adds them
to the parameters used globally when running all test suites. That
means that a target like `check-all`, which ends up calling Lit on
the whole monorepo, will see the test parameters for all the individual
project's test suites.

So, for example, it would see `--param std=c++03` (from libc++abi), and
`--param std=c++03` (from libc++), and `--param whatever` (from another
project being tested at the same time). While always unclean, that works
when the parameters all agree. However, if the parameters share the same
name but have different values, only one of those two values will be used
and it will be incredibly confusing to understand why one of the test
suites is being run with the incorrect parameter value.

For that reason, this commit moves away from using add_lit_testsuite()'s
PARAM functionality, and serializes the parameter values for the runtimes
in the generated config.py file instead, which is local to the specific
test suite.

Differential Revision: https://reviews.llvm.org/D105991
2021-07-15 07:53:15 -04:00
Louis Dionne 850b57c5fb [runtimes] Bring back TARGET_TRIPLE
This commit reverts 5099e01568 and 77396bbc98, which broke the build
in various ways. I'm reverting until I can investigate, since that
change appears to be way more subtle than it seemed.
2021-07-14 15:15:22 -04:00
Louis Dionne 77396bbc98 [runtimes] NFCI: Drop intermediate CMake variable TARGET_TRIPLE
We might as well use the various XXX_TARGET_TRIPLE variables directly.
2021-07-14 10:49:28 -04:00
Louis Dionne 2a399e60b6 [libc++] Add a CI job for macOS on arm64 hardware 🥳
Differential Revision: https://reviews.llvm.org/D105848
2021-07-13 13:49:05 -04:00