[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