This is a direct port of the new PE/COFF linker to ELF. It can link simple object files, but doesn't do relocations yet.
The plan for this is to implement gnu-ld semantics and see what code can be shared with the new PE/COFF implementation, if any.
Differential D11188
[LLD] New ELF implementation Bigcheese on Jul 14 2015, 11:27 AM. Authored by
Details
This is a direct port of the new PE/COFF linker to ELF. It can link simple object files, but doesn't do relocations yet. The plan for this is to implement gnu-ld semantics and see what code can be shared with the new PE/COFF implementation, if any.
Diff Detail
Event TimelineComment Actions Just a few nits. The patch contains some code copied from COFF especially in the driver. Do you plan to cleanup it before commit?
Comment Actions I want you to strip this patch even more. Especially I'd like you to remove LTO completely from this initial patch. LTO code is fairly large but totally dead and untested. We can restore that when we actually start working on that. I'd also want you to remove Windows-specific code as I left comments. Overall, the code looks good -- if I'm eligible to say that. This is really a direct translation of my COFF linker to ELF, and of course I didn't find any difficulty to read and understand the code. The duplication of code with COFF is a bit concerning, but I'd imagine that if we try to merge this with COFF, it would become very messy because so many little things are different in many places. This is what I learned from the old LLD. We'd have eventually had to add tons of hooks and virtual function calls everywhere. So I think this is practical approach to port the COFF linker to ELF. We should keep COFF and ELF in sync as much as possible, and factor out common code to libObject or other LLVM library to remove code from COFF or ELF directories. Regarding Windows-ness of the COFF linker which has been directly copied to this ELF port. The symbol resolution semantics in particular is not compatible with ELF. As I described in COFF/README.md, the symbol table and SymbolBodies implement Windows symbol resolution semantics. As a result, this ELF linker would behave as if all input files are wrapped with --start-group and --end-group. This would be more efficient than the regular Unix linker because the Unix semantics is too dumb, but it's not fully compatible with other linkers (although it's mostly compatible IMO). So there's a tradeoff between "new, efficient but incompatible way" and "dumb but compatible way". I'm totally on the side to keep this new semantics in this ELF linker. --start-gropu and --end-group is a hack to deal with Unix linker's dumb semantics, and if we can replace that with better semantics, we should do that using this chance to rewrite a ELF linker. This is much better than before, and it open the possibility of significant optimization. I also think that we can implement backward-compatible mode to this ELF linker without too much trouble. My ambition is that ultimately we would provide "better and mostly compatible" and "slow and fully compatible" options to the user and let users to choose the former. I imagine that that can even be a strong reason to choose LLD over other ELF linkers in the future.
Comment Actions I don't understand how forcing everything to be grouped can make things more efficient, given that it is strictly required to do more work. It doesn't even matter for plain object files, just for libraries. In the case of libraries, there are subtle error cases involving weak symbols, so please do *not* change the resolution algorithm. Comment Actions Address review comments.
Comment Actions LGTM Please leave this for a while so that other people can review this patch as well.
Comment Actions I am currently rebasing this on trunk.
Comment Actions A patch that builds on trunk is attached. I have also fixed it to build when using shared libraries. There is still a *lot* of stuff that should be deleted before this
This comment was removed by Bigcheese. Comment Actions The attached patch looks good to me. It is your patch, but I have:
Even with the extra tests this patch adds 1255 lines. Yours was 1995. Cheers, |