[PATCH] D51902: [SanitizerCoverage] Create comdat for global arrays.

Matt Morehouse via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Sep 11 15:40:29 PDT 2018


morehouse added inline comments.


================
Comment at: llvm/trunk/lib/Transforms/Instrumentation/SanitizerCoverage.cpp:582
+      std::string ModuleId = getUniqueModuleId(CurModule);
+      Name += ModuleId.empty() ? CurModule->getModuleIdentifier() : ModuleId;
+    }
----------------
morehouse wrote:
> eugenis wrote:
> > I don't think this is correct - getModuleIdentifier() is even less unique then getUniqueModuleId, and comdat names for local linkage functions really have to be unique.
> > 
> > Imagine two files with the same relative path, no exported symbols, defining local functions with the same name. We don't want them to share a comdat.
> > 
> > I think this case needs to fallback to non-comdat non-associated instrumentation (the one that suppressed linker GC).
> > 
> Ah, I see.  Will revert.
> 
> Hopefully suppressing GC for that case won't cause any regressions (e.g., https://github.com/google/sanitizers/issues/971).
Hmm... That approach gives me link errors again:

```
/usr/bin/ld: __sancov_pcs has both ordered [`__sancov_pcs[SSL_COMP_get_name]' in BUILD/libssl.a(ssl_ciph.o)] and unordered [`__sancov_pcs' in BUILD/libssl.a(ssl_ciph.o)] sections
```

I guess the linker doesn't like having some arrays in comdats and some not in comdats within the same section.


Repository:
  rL LLVM

https://reviews.llvm.org/D51902





More information about the llvm-commits mailing list