COFF has a verifier check that private global variables don't have a comdat of the same name.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I'm not sure if I'm understanding the intent of the verifier check correctly. Is it that all private GVs on COFF shouldn't have a comdat, or they specifically shouldn't have a comdat of the same name?
I don't think this current revision will work, I don't imagine you would be able to build Chrome for Windows with coverage with this change, or if you did, the binary and object file sizes would be much larger.
llvm/test/Instrumentation/InstrProfiling/comdat.ll | ||
---|---|---|
33 | This seems like an interesting behavior change. Why do we want this? The intention of the current structure is that the profd data reuses the profc comdat, so we don't need to include profd in the symbol table. I believe I did this to reduce object file size and symbol table size. If we don't use a comdat here, then we will end up with extra duplicate profd data that we don't want. | |
60 | It sounds like the real corner case here is doing coverage for functions with private linkage. To handle that case, I think we should make the __profc data internal linkage instead of private. Internal linkage will produce a symbol table entry which can be used with comdats. |
llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp | ||
---|---|---|
1031 | linkage is already set here |
lgtm
llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp | ||
---|---|---|
917–918 | I would phase this differently: COFF doesn't allow the comdat group leader to have private linkage, so upgrade private linkage to internal linkage to produce a symbol table entry. That's the difference between private and internal linkage, at least for ELF and COFF: whether or not there is a symbol table entry. COFF comdat info lives in the symbol table, so if you don't have one, you can't be a comdat symbol. I think the next best alternative fix would be to paper over this platform specific detail in the backend, and produce symbol table entries for private+comdat symbols. I don't recall why the verifier error was preferred over this. |
I would phase this differently: COFF doesn't allow the comdat group leader to have private linkage, so upgrade private linkage to internal linkage to produce a symbol table entry.
That's the difference between private and internal linkage, at least for ELF and COFF: whether or not there is a symbol table entry. COFF comdat info lives in the symbol table, so if you don't have one, you can't be a comdat symbol.
I think the next best alternative fix would be to paper over this platform specific detail in the backend, and produce symbol table entries for private+comdat symbols. I don't recall why the verifier error was preferred over this.