[PATCH] [ELF] LLD does not create a record in the .dynsym if a strong symbol defined in the executable file replaces a weak symbol from a shared library.
Rui Ueyama
ruiu at google.com
Tue Aug 5 13:13:03 PDT 2014
I'd think we shouldn't subclass Resolver class. Windows linker is probably more different from the original Resolver class behavior but we can still be able to share the class. Also Resolver class already contains some arch/binary format specific code -- for example, fallback atom for Windows and GNU LinkOnce attribute for ELF. I understand the reason why you are adding this code, but what this patch is trying to do seems rather simple compared to its patch size. It feels it's probably better not to subclassing the entire class but instead add a few lines to Resolver directly.
That being said, I don't have a concrete idea on how to do it. The issue is that we lose the information that an undefined atom had after it's coalesced away. That happens in Resolver::updateReference(), in which we completely ditches coalesed-away atoms. Maybe we should add code there to copy some information from a coalesed-away atom to a replacing atom. Then the ELF writer is able to see that to decide if it needs a .dynsym entry for a replacement atom.
http://reviews.llvm.org/D4789
More information about the llvm-commits
mailing list