[PATCH] D28436: [Sanitizer Coverage] Modify initialization of array bounds for sanitizer coverage.

Marcos Pividori via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 6 20:32:09 PST 2017


mpividori created this revision.
mpividori added reviewers: kcc, aizatsky, rnk, zturner.
mpividori added a subscriber: llvm-commits.
mpividori set the repository for this revision to rL LLVM.

There is an important difference in how the linker handles sections on Windows.
As mentioned in https://msdn.microsoft.com/en-us/library/7977wcck.aspx , the linker can include some zero padding between each part of the section when merging. Which means, it can include some zero padding between `__start___sancov_guards` and the first guard array, between the arrays and between the final array and `__stop___sancov_guards`.
In practice, I only see this zero padding when linking "incrementally", but I couldn't find official documentation, so this could also happen when linking non incrementally.

So, to deal with this difference, I simply modified the implementation of the instrumentation, to initialize the integers in the guard arrays with 0xffffffff  , so we can distinguish between the parts of the section that belongs to a guard array and the part of the sections that represents zero padding.

For example, when I compile a simple test with "-fsanitize-coverage=trace-pc-guard"  , link incrementally and execute "dumpbin /section:.CSAN /rawdata my_test.exe" , I get:

RAW DATA #4

  051A6000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  051A6010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  ......
  051A6110: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
  051A6120: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
  051A6130: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
  051A6140: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
  051A6150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  051A6160: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
  051A6170: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
  051A6180: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
  051A6190: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
  051A61A0: 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF  ............ÿÿÿÿ
  051A61B0: FF FF FF FF FF FF FF FF FF FF FF FF 00 00 00 00  ÿÿÿÿÿÿÿÿÿÿÿÿ....
  051A61C0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
  051A61D0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
   .......
  051A6230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
   .....

(the parts of the section with "FF" represent the guard arrays)

So, when initializing the arrays guards, we will iterate from  `&__start___sancov_guard`s to  `&__stop___sancov_guards` considering only the positions with value 0xffffffff

(In a different diff I update the implementation of sanitizer coverage to work with these changes).


Repository:
  rL LLVM

https://reviews.llvm.org/D28436

Files:
  lib/Transforms/Instrumentation/SanitizerCoverage.cpp


Index: lib/Transforms/Instrumentation/SanitizerCoverage.cpp
===================================================================
--- lib/Transforms/Instrumentation/SanitizerCoverage.cpp
+++ lib/Transforms/Instrumentation/SanitizerCoverage.cpp
@@ -520,7 +520,7 @@
   ArrayType *ArrayOfInt32Ty = ArrayType::get(Int32Ty, NumGuards);
   FunctionGuardArray = new GlobalVariable(
       *CurModule, ArrayOfInt32Ty, false, GlobalVariable::PrivateLinkage,
-      Constant::getNullValue(ArrayOfInt32Ty), "__sancov_gen_");
+      Constant::getAllOnesValue(ArrayOfInt32Ty), "__sancov_gen_");
   if (auto Comdat = F.getComdat())
     FunctionGuardArray->setComdat(Comdat);
   FunctionGuardArray->setSection(getSanCovTracePCGuardSection());


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D28436.83497.patch
Type: text/x-patch
Size: 727 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170107/a1a02425/attachment.bin>


More information about the llvm-commits mailing list