http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #14 from Rafael Avila de Espindola <rafael.espindola at gmail dot com> 2011-02-15 19:39:09 UTC --- Sorry, can you expand on what gcc was doing that was causing it to expand the dynamic symbol table? With LLVM what we are doing is *) Report all symbols *) Any symbol not given a PREVAILING_DEF, we make it internal. *) All other symbols stay the same. For example, a vtable is normally produce as a symbol with linkonce_odr (see http://llvm.org/docs/LangRef.html#linkage_linkonce_odr). If it is not used, we drop it. The potential problem with what LLVM is doing (I don't have a seem it in practice, but haven't tried to force it) is the case * file a.cc has the vtable for class foo and a use of it * file b.cc has the vtable for class foo and a use of it We produce IL for a.cc and a ELF for b.cc. Gold decides to use the IL version, gives the plugin a PREVAILING_DEF. LLVM optimises the use away and drops the vtable. We now have an undefined reference to the vtable. With both PREVAILING_DEF_IRONLY_EXP and PREVAILING_DEF llvm would be able to tell the difference. If there was no use of the vtable from an ELF file, gold would give a PREVAILING_DEF_IRONLY_EXP and llvm would be allowed to drop it. If there is, gold gives a PREVAILING_DEF and llvm must upgrade the vtable from linkonce_odr to weak_odr which causes it to say in the final .o even if it optimises out all uses.
