If there are any intrinsics that cannot be traced back to an alloca, we might have missed the start of a variable's scope, leading to false error reports if the variable is poisoned at function entry. Instead, if there are some intrinsics that can't be traced, fail safe and don't poison the variables in that function.
Details
Diff Detail
Event Timeline
LGTM
Consider extending the test with another alloca which does not participate in any untraceable lifetimes, but has to be poisoned in entry block anyway.
llvm/test/Instrumentation/AddressSanitizer/stack-poisoning-and-lifetime.ll | ||
---|---|---|
223 | did you mean "should poison"? |
llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp | ||
---|---|---|
922 | How often does this happen? |
But if there are untraceable lifetimes, we don't know what allocas might potentially be involved. At least not as the code currently works, where it doesn't trace selects and phis with different values.
llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp | ||
---|---|---|
922 | I think it's very rare, but it happens. We didn't run into it in any Chromium tests, but one test in V8 did. I think just bailing out for such functions is okay. | |
llvm/test/Instrumentation/AddressSanitizer/stack-poisoning-and-lifetime.ll | ||
223 | No, I mean shouldn't poison. Since we don't know the lifetimes we can't poison it. Or am I missing something? |
llvm/test/Instrumentation/AddressSanitizer/stack-poisoning-and-lifetime.ll | ||
---|---|---|
223 | Well, we shouldn't poison them at lifetime intrinsic. |
llvm/test/Instrumentation/AddressSanitizer/stack-poisoning-and-lifetime.ll | ||
---|---|---|
223 | Ah, I get what you mean. We should not poison alloca contents, only their redzones. |
How often does this happen?
If often then maybe we should try to limit only that to allocas involved into such conflicts?