[PATCH] D19921: [esan] EfficiencySanitizer shadow memory

[Derek Bruening via llvm-commits]

bruening added inline comments.

================
Comment at: lib/esan/esan_shadow.h:79
@@ +78,3 @@
+//
+// We also want to ensure that a wild access by the application into the shadow
+// regions will not corrupt our own shadow memory.  shadow(shadow) ends up
----------------
aizatsky wrote:
> The protection from this kind of wild access adds significant complexity to the mapping scheme. Is it really important for esan? 
> 
> I can imagine this being important for asan, even though it seems to ignore this issue atm. Do we really need this complexity?
IMHO this is not adding much complexity: the offset for two of the scale values is tweaked slightly from the formula.  It makes the mapping more robust and has no performance cost in the fastpath.  This general mapping could potentially be used for other non-efficiency sanitizers in the future.  I don't see much value in removing a robustness feature from the mapping.


http://reviews.llvm.org/D19921