This is an archive of the discontinued LLVM Phabricator instance.

[ASan] Don't instrument promotable dynamic allocas.
ClosedPublic

Authored by samsonov on Sep 8 2015, 1:48 PM.

Details

Summary

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.

Diff Detail

Repository
rL LLVM

Event Timeline

samsonov updated this revision to Diff 34252.Sep 8 2015, 1:48 PM
samsonov retitled this revision from to [ASan] Don't instrument promotable dynamic allocas..
samsonov updated this object.
samsonov added a reviewer: ygribov.
samsonov added a subscriber: llvm-commits.
samsonov updated this revision to Diff 34370.Sep 9 2015, 2:52 PM
  • [ASan] Handle lifetime intrinsics before handling dynamic allocas.
m.ostapenko edited edge metadata.Sep 10 2015, 9:01 AM

Thanks for fixing this! Just one question below.

lib/Transforms/Instrumentation/AddressSanitizer.cpp
1800 ↗(On Diff #34370)

lifetime intrinsics may refer to dynamic allocas, so we need to emit instrumentation before these dynamic allocas would be replaced.

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?

m.ostapenko accepted this revision.Sep 28 2015, 7:42 AM
m.ostapenko edited edge metadata.

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.

This revision is now accepted and ready to land.Sep 28 2015, 7:42 AM

Alexey, could you commit this please? It would be very nice to try enable dynamic alloca instrumentation in Clang.

Looking into this now. Sorry for the delay!

samsonov added inline comments.Oct 22 2015, 12:52 PM
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.

This revision was automatically updated to reflect the committed changes.