We already have a test that checks that promotable dynamic allocas are
ignored, as well as static promotable allocas. Make sure this test will
still pass if/when we enable dynamic alloca instrumentation by default.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Thanks for fixing this! Just one question below.
lib/Transforms/Instrumentation/AddressSanitizer.cpp | ||
---|---|---|
1800 ↗ | (On Diff #34370) |
Well, if we instrument dynamic alloca related to some lifetime intrinsic first time and instrument it in handleDynamicAllocaCall() second time, we may end up with redzones would be mixed, right? Anyway, looking to poisonAlloca(...) function: void FunctionStackPoisoner::poisonAlloca(Value *V, uint64_t Size, IRBuilder<> &IRB, bool DoPoison) { // For now just insert the call to ASan runtime. Value *AddrArg = IRB.CreatePointerCast(V, IntptrTy); Value *SizeArg = ConstantInt::get(IntptrTy, Size); IRB.CreateCall( DoPoison ? AsanPoisonStackMemoryFunc : AsanUnpoisonStackMemoryFunc, {AddrArg, SizeArg}); } Size parameter is uint64_t, so it seems we can poison static allocas only. So, I'm wondering, is that the case? |
Ah, right, I see that we indeed can mess with dynamic allocas and lifetime intrinsics here (in such cases, when alloca's size is known in compile time, but it's treated as dynamic one for others reasons).
Alexey, could you please land this?
Thanks!
lib/Transforms/Instrumentation/AddressSanitizer.cpp | ||
---|---|---|
433 ↗ | (On Diff #34370) | I wonder if we should remove isArrayAllocation() from this filter. |
Alexey, could you commit this please? It would be very nice to try enable dynamic alloca instrumentation in Clang.
lib/Transforms/Instrumentation/AddressSanitizer.cpp | ||
---|---|---|
433 ↗ | (On Diff #34370) | Let's handle this separately. |
1800 ↗ | (On Diff #34370) | Yes. Alloca will be treated as "dynamic" if it has constant size, but it's not located in the function entry block, for instance. AsanPoisonStackMemoryFunc is severely undertested (and half-dead), specially in presence of dynamic allocas, so for now I think it's fine to keep "correctness" in the sense of "keep tests we have working". I'm not sure that poisoning left and right redzoes in __asan_alloca_poison() would conflict with poisoning the alloca itself on lifetime intrinsics. |