http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #16 from Rafael Avila de Espindola <rafael.espindola at gmail dot com> 2011-02-16 04:03:36 UTC --- > 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. I see. Even with PREVAILING_DEF_IRONLY_EXP we still have to update gold to drop those, no? Gold doesn't know the language semantics to know which visible symbols can or cannot be dropped, so it can only assume the plugin knows what it is doing when it drops one. > > 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. Yes, the common case is to try to put as much as possible in the IL :-) Now that I can build firefox in LTO I will try to create a testcase for this next week. > > > > 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. Well, since we know this is the symbol being used, llvm can just upgrade it all the way to a regular symbol. > Honza Thanks, Rafael
