[all-commits] [llvm/llvm-project] 2d6906: Recommit DwarfEHPrepare: insert extra unwind paths...

[Tim Northover via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 2d690684f66fabc9ac6a2c70fcff3b31c9520794
      https://github.com/llvm/llvm-project/commit/2d690684f66fabc9ac6a2c70fcff3b31c9520794
  Author: Tim Northover <tnorthover at apple.com>
  Date:   2023-03-16 (Thu, 16 Mar 2023)

  Changed paths:
    M llvm/lib/CodeGen/DwarfEHPrepare.cpp
    A llvm/test/CodeGen/AArch64/safestack-unwind.ll

  Log Message:
  -----------
  Recommit DwarfEHPrepare: insert extra unwind paths for stack protector to instrument

This is a mitigation patch for
https://bugs.chromium.org/p/llvm/issues/detail?id=30, where existing stack
protection is skipped if a function is returned through by an unwinder rather
than the normal call/return path. The recent patch D139254 added the ability to
instrument a visible unwind path, at least in the IR case (I'm working on the
SelectionDAG instrumentation too) but there are still invisible unwinds it
can't reach.

So this patch adds logic to DwarfEHPrepare that goes through a function,
converting any call that might throw into an invoke to a simple resume cleanup,
and adding cleanup clauses to existing landingpads that lack them. Obviously we
don't really want to do this if it's wasted effort, so I also exposed
requiresStackProtector from the actual StackProtector code to skip the extra
paths if they won't be used.

Changes:
  * Move test to AArch64 directory as it relies on target presence.
  * Re-add Dominator-tree maintenance. Accidentally cherry-picked wrong patch.
  * Skip adding paths on Windows EH functions.

https://reviews.llvm.org/D143637