> If we get into extending linker plugin interface, it would be great if we > would > do somehting about COMDAT. We now have RESOLVED and RESOLVED_IRONLY, while > the > problem is that all non-hidden COMDAT symbols get RESOLVED that pretty much > fixes them in the output library. > > I would propose adding RESOLVED_IRDYNAMIC for cases where symbol was resolved > IRONLY except that it is externally visible to dynamic linker. We can then > allow > compiler to optimize this symbol out (same way as IRONLY) if it knows it may > or > may not be exported - i.e. from COMDAT flag or via -fwhole-program.
(This is off the main topic...) Actually, we have PREVAILING_DEF and PREVAILING_DEF_IRONLY, plus RESOLVED_IR, RESOLVED_EXEC, and RESOLVED_DYN. If the symbol was resolved elsewhere, we don't have any way to say whether it was IRONLY or not, and that's a problem for common symbols, because there really is no prevailing def -- the linker just allocates the space itself. Currently, gold picks one of the common symbols and calls it the prevailing def, but the one it picks might not actually be the largest one. I'd prefer to add something like COMMON and COMMON_IRONLY as possible resolutions. I'm not sure if you're talking about that, or about real COMDAT groups. As far as gold is concerned, it picks one COMDAT group and throws the rest of them away, but for the one it picks, you'll get either PREVAILING_DEF or PREVAILING_DEF_IRONLY. That should tell the compiler what it needs to know. I'm also not sure what you mean by "resolved IRONLY except that it is externally visible to the dynamic linker." If we're building a shared library, and the symbol is exported, it's not going to be IRONLY, and I don't see how it would be valid to optimize it out. If we're building an executable with --export-dynamic, same thing. -cary
