[PATCH] D56624: [Sanitizers] UBSan unreachable incompatible with ASan in the presence of `noreturn` calls

Vedant Kumar via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Jan 24 14:52:39 PST 2019


vsk added a comment.

In D56624#1370243 <https://reviews.llvm.org/D56624#1370243>, @eugenis wrote:

> > Because "expect_noreturn" calls are allowed to return, the compiler must behave as they could. In particular, this means that unpoisoning the stack before expect_noreturn calls (given the current semantics) is premature.
>
> I don't think that's true. A hypothetical function
>
>   maybe_longjmp(jmp_buf env)
>
> that checks an opaque condition needs stack unpoisoning before the call, in the absense of a better solution.


Wouldn’t it be preferable to unpoison the stack inside of maybe_longjmp, once the opaque condition can be checked? Even if not, a narrower sanitizer_noreturn attribute is still perfectly fine, here.

> One possible optimization that I can think of is splitting code after the call into a separate basic block and marking it as cold.
>  Admittedly, that's unlikely to have big impact in practice. I'd guess that [[expect_noreturn]] calls are typically not very hot in the first place.

The cold attribute is already used for this kind of splitting/reordering. I don't yet see how expect_noreturn creates new opportunities for the optimizer.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56624





More information about the cfe-commits mailing list