MinGW configurations don't use associative comdats, as GNU ld doesn't support that. Instead they produce normal comdats named .text$sym, .xdata$sym and .pdata$sym.
GNU ld doesn't discard any comdats starting with .xdata or .pdata, even if --gc-sections is used (while it does discard other unreferenced comdats), regardless of what symbol name is used after the $ separator.
For LLD, treat any such comdat as implicitly associative to the base symbol. This requires maintaining a map from symbol name to section number, but that is only maintained when the MinGW flag has been enabled.
Is there some way we can hash fewer symbols? It's unfortunate that we need a string hash table at all to parse object files. I wonder if there's a way we can defer this work, since for C++, a lot of comdat things end up getting discarded.
If we do need a string hash table, it should probably be a DenseMap<StringRef, uint32_t>, since this is performance critical.
Oh, here's an idea: maybe createDefined should return Prevailing somehow. Only add the symbol to the table if it's a prevailing comdat symbol in an executable section.