Index: lld/trunk/docs/NewLLD.rst =================================================================== --- lld/trunk/docs/NewLLD.rst +++ lld/trunk/docs/NewLLD.rst @@ -53,7 +53,7 @@ until we need them to continue linking. When we need to do some costly operation (such as looking up a hash table for each symbol), we do it only once. - We obtain a handler (which is typically just a pointer to actual data) + We obtain a handle (which is typically just a pointer to actual data) on the first operation and use it throughout the process. * Efficient archive file handling @@ -90,18 +90,18 @@ `--end-group`, to let the linker loop over the files between the options until no new symbols are added to the set. - Visiting the same archive files multiple makes the linker slower. + Visiting the same archive files multiple times makes the linker slower. Here is how LLD approaches the problem. Instead of memorizing only undefined symbols, we program LLD so that it memorizes all symbols. When it sees an undefined symbol that can be resolved by extracting an object file from an - archive file it previously visited, it immediately extracts the file and link - it. It is doable because LLD does not forget symbols it have seen in archive + archive file it previously visited, it immediately extracts the file and links + it. It is doable because LLD does not forget symbols it has seen in archive files. - We believe that the LLD's way is efficient and easy to justify. + We believe that LLD's way is efficient and easy to justify. - The semantics of LLD's archive handling is different from the traditional + The semantics of LLD's archive handling are different from the traditional Unix's. You can observe it if you carefully craft archive files to exploit it. However, in reality, we don't know any program that cannot link with our algorithm so far, so it's not going to cause trouble. @@ -157,7 +157,7 @@ - Undefined symbols represent undefined symbols, which need to be replaced by Defined symbols by the resolver until the link is complete. - Lazy symbols represent symbols we found in archive file headers - which can turn into Defined if we read archieve members. + which can turn into Defined if we read archive members. There's only one Symbol instance for each unique symbol name. This uniqueness is guaranteed by the symbol table. As the resolver reads symbols from input Index: lld/trunk/docs/index.rst =================================================================== --- lld/trunk/docs/index.rst +++ lld/trunk/docs/index.rst @@ -1,7 +1,7 @@ LLD - The LLVM Linker ===================== -LLD is a linker from the LLVM project. That is a drop-in replacement +LLD is a linker from the LLVM project that is a drop-in replacement for system linkers and runs much faster than them. It also provides features that are useful for toolchain developers. @@ -17,7 +17,7 @@ Features -------- -- LLD is a drop-in replacement for the GNU linkers. That accepts the +- LLD is a drop-in replacement for the GNU linkers that accepts the same command line arguments and linker scripts as GNU. We are currently working closely with the FreeBSD project to make @@ -30,29 +30,27 @@ `_. - LLD is very fast. When you link a large program on a multicore - machine, you can expect that LLD runs more than twice as fast as GNU + machine, you can expect that LLD runs more than twice as fast as the GNU gold linker. Your milage may vary, though. - It supports various CPUs/ABIs including x86-64, x86, x32, AArch64, ARM, MIPS 32/64 big/little-endian, PowerPC, PowerPC 64 and AMDGPU. - Among these, x86-64 is the most well-supported target and have - reached production quality. AArch64 and MIPS seem decent too. x86 - should be OK but not well tested yet. ARM support is being developed - actively. + Among these, x86-64, AArch64, and ARM (>= v6) are production quality. + MIPS seems decent too. x86 should be OK but is not well tested yet. - It is always a cross-linker, meaning that it always supports all the above targets however it was built. In fact, we don't provide a build-time option to enable/disable each target. This should make it easy to use our linker as part of a cross-compile toolchain. -- You can embed LLD to your program to eliminate dependency to +- You can embed LLD in your program to eliminate dependencies on external linkers. All you have to do is to construct object files and command line arguments just like you would do to invoke an external linker and then call the linker's main function, ``lld::elf::link``, from your code. - It is small. We are using LLVM libObject library to read from object - files, so it is not completely a fair comparison, but as of February + files, so it is not a completely fair comparison, but as of February 2017, LLD/ELF consists only of 21k lines of C++ code while GNU gold consists of 198k lines of C++ code. @@ -102,8 +100,8 @@ details, see `Getting Started with the LLVM System `_. -If you haven't checkout out LLVM, the easiest way to build LLD is to -checkout the entire LLVM projects/sub-projects from a git mirror and +If you haven't checked out LLVM, the easiest way to build LLD is to +check out the entire LLVM projects/sub-projects from a git mirror and build that tree. You need `cmake` and of course a C++ compiler. .. code-block:: console Index: lld/trunk/docs/open_projects.rst =================================================================== --- lld/trunk/docs/open_projects.rst +++ lld/trunk/docs/open_projects.rst @@ -3,8 +3,6 @@ Open Projects ============= -.. include:: ../include/lld/Core/TODO.txt - Documentation TODOs ~~~~~~~~~~~~~~~~~~~ Index: lld/trunk/docs/windows_support.rst =================================================================== --- lld/trunk/docs/windows_support.rst +++ lld/trunk/docs/windows_support.rst @@ -20,8 +20,8 @@ almost all command line options that the linker shipped with Microsoft Visual C++ (link.exe) supports. -The current status is that LLD can link itself on Windows x86/x64 -using Visual C++ 2013 as the compiler. +The current status is that LLD is used to link production builds of large +real-world binaries such as Firefox and Chromium. Development status ================== Index: lld/trunk/include/lld/Core/TODO.txt =================================================================== --- lld/trunk/include/lld/Core/TODO.txt +++ lld/trunk/include/lld/Core/TODO.txt @@ -1,14 +0,0 @@ -include/lld/Core -~~~~~~~~~~~~~~~~ - -* The yaml reader/writer interfaces should be changed to return - an explanatory string if there is an error. The existing error_code - abstraction only works for returning low level OS errors. It does not - work for describing formatting issues. - -* We need to add more attributes to File. In particular, we need cpu - and OS information (like target triples). We should also provide explicit - support for `LLVM IR module flags metadata`__. - -.. __: http://llvm.org/docs/LangRef.html#module_flags -.. _Clang: http://clang.llvm.org/docs/InternalsManual.html#Diagnostics