[PATCH] D137381: [clang][compiler-rt] Exception escape out of an non-unwinding function is an undefined behaviour

Roman Lebedev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jan 10 06:22:35 PST 2023


lebedev.ri added a comment.

In D137381#4038716 <https://reviews.llvm.org/D137381#4038716>, @MaskRay wrote:

> I am unfamiliar with Clang codegen so I am just commenting about what a user may feel about this feature.
>
> `compiler-rt/test/ubsan/TestCases/Misc/exception-escape.cpp` cannot demonstrate the value of the new UBSan check `-fsanitize=exception-escape`, as the executable will fail without the option (Clang emits `call` instead of `invoke` for a nounwind function call, and there is no LSDA information, libgcc/libunwind will call terminate; it's trivial to get more diagnostic with a SIBABRT signal handler).
> To demonstrate the value, `footgun` and its caller need to be in different TUs and the caller does not know `footgun` is nounwind.
> In such a setup, I think people likely care more about `-fno-exceptions`/`-fexceptions` exception propagation instead of `__attribute__((pure))` and find `-fsanitize=exception-escape` not do what it may advertise.
>
> The more common `-fno-exceptions`/`-fexceptions` exception propagation dilemma can be detected today with `-fno-asynchronous-unwind-tables`.

Thank you for taking a look. I'm afraid this review comment is not based on reality, so i'm forced to ignore it.
The whole point of the clang change is to *NOT* lower such calls that we "know" will not unwind to a `call`, but into an `invoke`, with sanitization in the `landingpad`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137381/new/

https://reviews.llvm.org/D137381



More information about the llvm-commits mailing list