[sanitizer] Caught global buffer underflow for first variable

[condy]

Summary

There is no left redzone for global variables, so the underflow of the first variable couldn't be caught.
This patch creates a zero-sized array before the first variable so the underflow of it could be observable.

[condy]

Fix some tests

[condy]

Fix some tests

[condy]

Fix all tests

[condy]

Fix typos

[vitalybuka]

Would you mind to add compiler-rt/test/asan which triggers this one?

[eugenis]

You are adding a new global to every translation unit.

• Private linkage would not allow them to be merged, this can have significant binary size and RAM overhead.
• There is no guarantee that any of these globals will end up to the left of any sanitized globals. With -fdata-sections, the linker is free to reorder.
• It is also not referenced from anything, so -gc-sections is likely to kill it.

It looks like this will only work in very limited circumstances.

[condy]

In D102592#2764085, @vitalybuka wrote:

Would you mind to add compiler-rt/test/asan which triggers this one?

Yes, I will.

[condy]

In D102592#2764357, @eugenis wrote:

You are adding a new global to every translation unit.

• Private linkage would not allow them to be merged, this can have significant binary size and RAM overhead.

Do you suggest linkonce linkage?

• There is no guarantee that any of these globals will end up to the left of any sanitized globals. With -fdata-sections, the linker is free to reorder.
• It is also not referenced from anything, so -gc-sections is likely to kill it.

It looks like this will only work in very limited circumstances.

Since it's limited, perhaps making it opt-in is a better choice. -asan-global-underflow or something else.

[eugenis]

I think it is too hit-and-miss to add even under a flag. It's just not the right approach - but I also don't know what the right approach would be.

Perhaps adding a small left redzone for all globals and reducing the right redzone to keep the total size under control? This way when most globals are instrumented we get approximately the same amount of redzone between any 2 of them, but also a little on the left of the first one.

[condy]

In D102592#2769811, @eugenis wrote:

I think it is too hit-and-miss to add even under a flag. It's just not the right approach - but I also don't know what the right approach would be.

Perhaps adding a small left redzone for all globals and reducing the right redzone to keep the total size under control? This way when most globals are instrumented we get approximately the same amount of redzone between any 2 of them, but also a little on the left of the first one.

Thanks for explanation, I will try your suggested approach.

[vitalybuka]

So I will hide it from "Ready to Review" list.

llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp

bool ModuleAddressSanitizer::InstrumentGlobals(IRBuilder<> &IRB, Module &M,
   }
 
   size_t n = GlobalsToChange.size();
   if (n == 0) {
     *CtorComdat = true;
     return false;
   }
 
+  // Create a global zero-sized array precedence before GlobalsToChange[0] so
+  // that the underflow of the it could be observable.
+  ArrayType *ZeroSizedArrayTy = ArrayType::get(IRB.getInt8Ty(), 0);
+  GlobalVariable *UnderflowObserverGV = new GlobalVariable(
+      M, ZeroSizedArrayTy, /*isConstant*/ false, GlobalVariable::PrivateLinkage,
+      ConstantArray::get(ZeroSizedArrayTy, {}), kAsanGenPrefix,
+      GlobalsToChange[0]);
+  GlobalsToChange.insert(GlobalsToChange.begin(), UnderflowObserverGV);
+
+  // Update size as we insert a dummy one.
+  n = GlobalsToChange.size();
+
   auto &DL = M.getDataLayout();
 
   // A global is described by a structure
   //   size_t beg;
   //   size_t size;
   //   size_t size_with_redzone;
   //   const char *name;
   //   const char *module_name;