Skip to content

Update libcxxabi to llvm-12 #14288

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 26, 2021
Merged

Update libcxxabi to llvm-12 #14288

merged 1 commit into from
May 26, 2021

Conversation

sbc100
Copy link
Collaborator

@sbc100 sbc100 commented May 25, 2021

Update libcxxabi to llvm-12

Followup to #14280

Changes from upstream can be seen at:
llvm/llvm-project@llvmorg-12.0.0...emscripten-core:emscripten-libs-12.0.0

Fixes: #14244

@sbc100 sbc100 changed the title Update libcxxabi Update libcxxabi to llvm-12 May 25, 2021
@sbc100 sbc100 changed the base branch from main to update_libcxx May 25, 2021 20:32
@sbc100 sbc100 requested a review from kripken May 25, 2021 20:33
@sbc100
Copy link
Collaborator Author

sbc100 commented May 25, 2021

Third part of a 3 part series!

@sbc100 sbc100 force-pushed the update_libcxxabi branch 2 times, most recently from d6ca966 to b8acb91 Compare May 25, 2021 20:35
Copy link
Member

@kripken kripken left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once more nice use of upstream work! (LIBCXXABI_NON_DEMANGLING_TERMINATE)

Base automatically changed from update_libcxx to main May 25, 2021 22:34
@sbc100 sbc100 force-pushed the update_libcxxabi branch from b8acb91 to 1e5139d Compare May 25, 2021 22:36
@sbc100 sbc100 enabled auto-merge (squash) May 25, 2021 22:36
@sbc100 sbc100 merged commit 43d6840 into main May 26, 2021
@sbc100 sbc100 deleted the update_libcxxabi branch May 26, 2021 01:03
aheejin added a commit to aheejin/emscripten that referenced this pull request Oct 5, 2022
In two-phase unwinding, the first phase is the search phase
(`_UA_SEARCH_PHASE`) and the second one is the cleanup phase
(`_UA_CLEANUP_PHASE`). The search phase searches up the stack to see if
there is a matching catch handler, and if it finds one, it caches the
result. And in the second cleanup phase, it retrieves the cached result
(to avoid doing same work twice) and unwinds the stack.

Wasm does not do the two-phase unwinding; it only has a single phase. We
used `_UA_CLEANUP_PHASE` for this single phase, so in Wasm the cleanup
phase is supposed to the search. So we several many custom `#ifdef`s to
use the code guarded by `_UA_SEARCH_PHASE`, for example:
https://github.com/aheejin/emscripten/blob/d57db5bea1719319a680699c50b91fa3d88fa0ec/system/lib/libcxxabi/src/cxa_personality.cpp#L771-L776
https://github.com/aheejin/emscripten/blob/d57db5bea1719319a680699c50b91fa3d88fa0ec/system/lib/libcxxabi/src/cxa_personality.cpp#L850-L855

These are apparently gone in emscripten-core#14288, which replaced many `if`s with
`assert`s. This in effect removed our special handling for
`_UA_CLEANUP_PHASE`; there are several `assert`s that asserts the
current phase is `_UA_SEARCH_PHASE`, while Wasm is in
`_UA_CLEANUP_PHASE`. But this has not caused problems so far because we
have built libc++abi with `-NDEBUG`, so all assertions were no-op.
https://github.com/emscripten-core/emscripten/blob/40fb7d2071e439f1de614898b88518df582faa94/tools/system_libs.py#L1366
But this is now a problem because emscripten-core#17979 adds a debug build of
libc++abi, which enables assertions.

Come to think of it, I'm not sure why I decided to use
`_UA_CLEANUP_PHASE` for our single phase in the first place. If we use
`_UA_SEARCH_PHASE`, we can remove more our custom code and reduce the
difference between our port and the upstream library.
aheejin added a commit that referenced this pull request Oct 5, 2022
In two-phase unwinding, the first phase is the search phase
(`_UA_SEARCH_PHASE`) and the second one is the cleanup phase
(`_UA_CLEANUP_PHASE`). The search phase searches up the stack to see if
there is a matching catch handler, and if it finds one, it caches the
result. And in the second cleanup phase, it retrieves the cached result
(to avoid doing same work twice) and unwinds the stack.

Wasm does not do the two-phase unwinding; it only has a single phase. We
used `_UA_CLEANUP_PHASE` for this single phase, so in Wasm the cleanup
phase is supposed to the search. So we several many custom `#ifdef`s to
use the code guarded by `_UA_SEARCH_PHASE`, for example:
https://github.com/aheejin/emscripten/blob/d57db5bea1719319a680699c50b91fa3d88fa0ec/system/lib/libcxxabi/src/cxa_personality.cpp#L771-L776
https://github.com/aheejin/emscripten/blob/d57db5bea1719319a680699c50b91fa3d88fa0ec/system/lib/libcxxabi/src/cxa_personality.cpp#L850-L855

These are apparently gone in #14288, which replaced many `if`s with
`assert`s. This in effect removed our special handling for
`_UA_CLEANUP_PHASE`; there are several `assert`s that asserts the
current phase is `_UA_SEARCH_PHASE`, while Wasm is in
`_UA_CLEANUP_PHASE`. But this has not caused problems so far because we
have built libc++abi with `-NDEBUG`, so all assertions were no-op.
https://github.com/emscripten-core/emscripten/blob/40fb7d2071e439f1de614898b88518df582faa94/tools/system_libs.py#L1366
But this is now a problem because #17979 adds a debug build of
libc++abi, which enables assertions.

Come to think of it, I'm not sure why I decided to use
`_UA_CLEANUP_PHASE` for our single phase in the first place. If we use
`_UA_SEARCH_PHASE`, we can remove more our custom code and reduce the
difference between our port and the upstream library.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Update libc++/libc++abi/compiler-rt to llvm-12
2 participants