Place global arrays in comdat sections with their associated functions.
This makes sure they are stripped along with the functions they
reference, even on the BFD linker.
Details
- Reviewers
eugenis - Commits
- rG3bea25e55436: [SanitizerCoverage] Create comdat for global arrays.
rG7ce60324321a: [SanitizerCoverage] Create comdat for global arrays.
rGeac270caf45c: [SanitizerCoverage] Create comdat for global arrays.
rL342186: [SanitizerCoverage] Create comdat for global arrays.
rL341987: [SanitizerCoverage] Create comdat for global arrays.
rL341951: [SanitizerCoverage] Create comdat for global arrays.
Diff Detail
- Repository
- rL LLVM
Event Timeline
LGTM
FTR, http://llvm.org/docs/LangRef.html#associated-metadata mentions that comdat is "recommended".
It would be nice to factor this out into a utility function (create associated global for a global) and use it in asan, too.
Btw what if getUniqueModuleId returns ""? It may happens for files without external symbols.
I think we need to fall back to non-GCed counters.
llvm/trunk/lib/Transforms/Instrumentation/SanitizerCoverage.cpp | ||
---|---|---|
600 | 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). |
llvm/trunk/lib/Transforms/Instrumentation/SanitizerCoverage.cpp | ||
---|---|---|
600 | 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). |
llvm/trunk/lib/Transforms/Instrumentation/SanitizerCoverage.cpp | ||
---|---|---|
600 | 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. |
llvm/trunk/lib/Transforms/Instrumentation/SanitizerCoverage.cpp | ||
---|---|---|
600 | Never seen this error before. Does the linker treat names with a dot as ordered by the part of the name that follows the dot? What if you replace the dot with something else? |
llvm/trunk/lib/Transforms/Instrumentation/SanitizerCoverage.cpp | ||
---|---|---|
600 | I don't think there's any dots in the comdat name or the section name... In the case above the section name is __sancov_pcs and the comdat name is SSL_COMP_get_name. |
The error was actually caused by setting associated metadata for some arrays and not others. By always setting the metadata, we can avoid the issue.
@eugenis: PTAL
llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp | ||
---|---|---|
576 ↗ | (On Diff #165001) | Don't call getUniqueModuleId for every function in a module, it's not exactly O(1). |
LGTM, I'm almost 100% sure this is safe, but I don't remember all the linker quirks around associated sections now.
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).