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

Thu Jan 24 11:21:47 PST 2019

vsk added a comment.

In D56624#1369767 <https://reviews.llvm.org/D56624#1369767>, @yln wrote:

> In D56624#1369635 <https://reviews.llvm.org/D56624#1369635>, @vsk wrote:
>
> > What are the advantages of a generalized expect_noreturn attribute, vs. a narrower attribute or intrinsic? The expect_noreturn semantics do not provide strong guarantees, and are not really orthogonal from the pre-existing cold attribute.
>
>
> @eugenis Do you want to chime in here?
>  I think they convey different meanings even if their treatment by the optimizer is similar. The `cold` attribute says nothing about whether or not a function is expected to return.

That's my point: it doesn't need to, because it's orthogonal. It's just a hint that a call is cold and could be profitable to split/reorder. Features of llvm IR generally try to be orthogonal to reduce complexity in the optimizer.

>> In particular, expect_noreturn doesn't even seem strong enough to allow ASan to unpoison its stack.
> 
> I am not sure I understand this part. Can you elaborate?

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.

Put another way, a frontend author may (understandably, but mistakenly!) attach expect_noreturn to calls which they expect to be cold. That would regress ASan coverage.

Repository:
  rL LLVM

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

https://reviews.llvm.org/D56624