[PATCH] asan: do not instrument direct inbounds accesses to stack variables

Dmitry Vyukov dvyukov at google.com
Wed Feb 25 07:14:09 PST 2015


uploaded new patch


================
Comment at: lib/Transforms/Instrumentation/AddressSanitizer.cpp:18
@@ -16,1 +17,3 @@
+#include "llvm/Analysis/TargetLibraryInfo.h"
+#include "llvm/Analysis/ValueTracking.h"
 #include "llvm/Transforms/Instrumentation.h"
----------------
zaks.anna wrote:
> These seem out of place - should be moved after ADT.
Done

================
Comment at: lib/Transforms/Instrumentation/AddressSanitizer.cpp:189
@@ -184,1 +188,3 @@
+       cl::desc("Don't instrument scalar stack variables"), cl::Hidden,
+       cl::init(true));
 
----------------
kcc wrote:
> zaks.anna wrote:
> > This makes me nervous. I don't think ObjectSizeOffsetEvaluator is used much. This should probably go through more testing, though I am not sure how to catch issues here since we are removing checking.
> ouch. Indeed, don't make it true by default for now. 
> Unfortunately, I don't know any good way to test complex optimizations that eliminate checks,
> and so I don't know what it will take us to enable this by default. 
> But at least having this code in trunk will simplify the experiments. 
> 
changed default value to false

================
Comment at: lib/Transforms/Instrumentation/AddressSanitizer.cpp:408
@@ -398,2 +407,3 @@
   bool GlobalIsLinkerInitialized(GlobalVariable *G);
+  bool isInboundsAccess(ObjectSizeOffsetEvaluator &ObjSizeEval, Value *Addr);
 
----------------
zaks.anna wrote:
> const?
done

================
Comment at: lib/Transforms/Instrumentation/AddressSanitizer.cpp:1502
@@ +1501,3 @@
+      getTLI();
+  ObjectSizeOffsetEvaluator ObjSizeEval(DL, TLI, F.getContext(), true);
+
----------------
zaks.anna wrote:
> /*RoundToAlign=*/true
done

================
Comment at: lib/Transforms/Instrumentation/AddressSanitizer.cpp:2058
@@ +2057,3 @@
+  int64_t Offset = dyn_cast<ConstantInt>(SizeOffset.second)->getSExtValue();
+  return Offset >= 0 && Offset + TypeSize / 8 <= Size;
+}
----------------
zaks.anna wrote:
> Why not use getTypeStoreSize()?
>   uint64_t getTypeStoreSizeInBits(Type *Ty) const {
>     return 8 * getTypeStoreSize(Ty);
>   }
> 
> Also, is overflow possible in these calculations?
> 
done

These are int64's. I don't see how overflow can happen.

http://reviews.llvm.org/D7583

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list