[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