[all-commits] [llvm/llvm-project] adf156: [libunwind] Inform ASan that resumption is noreturn

[Shoaib Meenai via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: adf1561d6ce8af057127c65af863b3f0e1c77e60
      https://github.com/llvm/llvm-project/commit/adf1561d6ce8af057127c65af863b3f0e1c77e60
  Author: Shoaib Meenai <smeenai at fb.com>
  Date:   2021-05-26 (Wed, 26 May 2021)

  Changed paths:
    M libunwind/src/libunwind.cpp

  Log Message:
  -----------
  [libunwind] Inform ASan that resumption is noreturn

If you're building libunwind instrumented with ASan, `_Unwind_RaiseException`
will poison the stack and then transfer control in a manner which isn't
understood by ASan, so the stack will remain poisoned. This can cause
false positives, e.g. if you call an uninstrumented function (so it
doesn't re-poison the stack) after catching an exception. Add a call to
`__asan_handle_no_return` inside `__unw_resume` to get ASan to unpoison
the stack and avoid this.

`__unw_resume` seems like the appropriate place to make this call, since
it's used for resumption by all unwind implementations except SJLJ. SJLJ
uses `__builtin_longjmp` to handle resumption, which is already
recognized as noreturn (and therefore ASan adds the `__asan_handle_no_return`
call itself), so it doesn't need any special handling.

PR32434 is somewhat similar (in particular needing a component built
without ASan to trigger the bug), and rG781ef03e1012, the fix for that
bug, adds an interceptor for `_Unwind_RaiseException`. This interceptor
won't always be triggered though, e.g. if you statically link the
unwinder into libc++abi in a way that prevents interposing the unwinder
functions (e.g. marking the symbols as hidden, using `--exclude-libs`,
or using `-Bsymbolic`). rG53335d6d86d5 makes `__cxa_throw` call
`__asan_handle_no_return` explicitly, to similarly avoid relying on
interception.

Reviewed By: #libunwind, compnerd

Differential Revision: https://reviews.llvm.org/D103002