http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #15 from Jan Hubicka <hubicka at ucw dot cz> 2011-02-15 23:20:40 UTC --- > 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 The problem is with dropping linkonce_odr that has been previously reported. This way gold will allocate entry in the dynamic symbol table (you can see it in nm of the final binary) with no definition/use. Once something is given PREVAILING_DEF, it can not be optimized away. > 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. Yes, that is problem, too, but I didn't see it in practice. > > 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. Yes, that seems right except that GCC makes difference in between comdat symbols that must stay even if they are optimized out and weak symbols since both are handled bit differently. I am not sure if updating comdat symbol to weak is safe in ELF world, probably Iant would know. Honza
