[all-commits] [llvm/llvm-project] cfe9cc: [libc++abi] Simplify scan_eh_tab
Fangrui Song via All-commits
all-commits at lists.llvm.org
Thu Jan 21 15:19:41 PST 2021
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: cfe9ccbddd98b55e49e46bb40877ece6a47a7625
https://github.com/llvm/llvm-project/commit/cfe9ccbddd98b55e49e46bb40877ece6a47a7625
Author: Fangrui Song <i at maskray.me>
Date: 2021-01-21 (Thu, 21 Jan 2021)
Changed paths:
M libcxxabi/src/cxa_personality.cpp
Log Message:
-----------
[libc++abi] Simplify scan_eh_tab
1.
All `_URC_HANDLER_FOUND` return values need to set `landingPad`
and its value does not matter for `_URC_CONTINUE_UNWIND`. So we
can always set `landingPad` to unify code.
2.
For an exception specification (`ttypeIndex < 0`), we can check `_UA_FORCE_UNWIND` first.
3.
The so-called type 3 search (`actions & _UA_CLEANUP_PHASE && !(actions & _UA_HANDLER_FRAME)`)
is actually conceptually wrong. For a catch handler or an unmatched dynamic
exception specification, `_UA_HANDLER_FOUND` should be returned immediately. It
still appeared to work because the `ttypeIndex==0` case would return
`_UA_HANDLER_FOUND` at a later time.
This patch fixes the conceptual error and simplifies the code by handling type 3
the same way as type 2 (which is also what libsupc++ does).
The only difference between phase 1 and phase 2 is what to do with a cleanup
(`actionEntry==0`, or a `ttypeIndex==0` is found in the action record chain):
phase 1 returns `_URC_CONTINUE_UNWIND` while phase 2 returns `_URC_HANDLER_FOUND`.
Reviewed By: #libc_abi, compnerd
Differential Revision: https://reviews.llvm.org/D93190
More information about the All-commits
mailing list