[lld] r239734 - COFF: Update README.

Rui Ueyama ruiu at google.com
Mon Jun 15 09:25:11 PDT 2015


Author: ruiu
Date: Mon Jun 15 11:25:11 2015
New Revision: 239734

URL: http://llvm.org/viewvc/llvm-project?rev=239734&view=rev
Log:
COFF: Update README.

Modified:
    lld/trunk/COFF/README.md

Modified: lld/trunk/COFF/README.md
URL: http://llvm.org/viewvc/llvm-project/lld/trunk/COFF/README.md?rev=239734&r1=239733&r2=239734&view=diff
==============================================================================
--- lld/trunk/COFF/README.md (original)
+++ lld/trunk/COFF/README.md Mon Jun 15 11:25:11 2015
@@ -19,7 +19,7 @@ This is a list of important data types i
 
 * SymbolBody
 
-  SymbolBody is a class for symbols, which may be created for symbols
+  SymbolBody is a class for symbols. They may be created for symbols
   in object files or in archive file headers. The linker may create
   them out of nothing.
 
@@ -55,10 +55,10 @@ This is a list of important data types i
 * Chunk
 
   Chunk represents a chunk of data that will occupy space in an
-  output. They may be backed by sections of input files, but can be
-  created for something different, if they are for common or BSS
-  symbols. The linker may also create chunks out of nothing to append
-  additional data to an output.
+  output. Each regular section becomes a chunk.
+  Chunks created for common or BSS symbols are not backed by sections.
+  The linker may create chunks out of nothing to append additional
+  data to an output.
 
   Chunks know about their size, how to copy their data to mmap'ed
   outputs, and how to apply relocations to them. Specifically,
@@ -70,8 +70,8 @@ This is a list of important data types i
   SymbolTable is basically a hash table from strings to Symbols, with
   a logic to resolve symbol conflicts. It resolves conflicts by symbol
   type. For example, if we add Undefined and Defined symbols, the
-  symbol table will keep the latter. If we add Undefined and Lazy
-  symbols, it will keep the latter. If we add Lazy and Undefined, it
+  symbol table will keep the latter. If we add Defined and Lazy
+  symbols, it will keep the former. If we add Lazy and Undefined, it
   will keep the former, but it will also trigger the Lazy symbol to
   load the archive member to actually resolve the symbol.
 
@@ -84,7 +84,7 @@ There are mainly three actors in this li
 
 * InputFile
 
-  InputFile is a superclass for file readers. We have a different
+  InputFile is a superclass of file readers. We have a different
   subclass for each input file type, such as regular object file,
   archive file, etc. They are responsible for creating and owning
   SymbolBodies and Chunks.
@@ -194,13 +194,13 @@ seconds, so we think the design is promi
 Link-Time Optimization
 ----------------------
 
-LTO is implemented by handling LLVM bitcode files as input files.
+LTO is implemented by handling LLVM bitcode files as object files.
 The linker resolves symbols in bitcode files normally. If all symbols
 are successfully resolved, it then calls an LLVM libLTO function
 with all bitcode files to convert them to one big regular COFF file.
 Finally, the linker replaces bitcode symbols with COFF symbols,
-so that we can link the input files as if they were in COFF format
-from the beginning.
+so that we can link the input files as if they were in the native
+format from the beginning.
 
 The details are described in this document.
 http://llvm.org/docs/LinkTimeOptimization.html





More information about the llvm-commits mailing list