Update comments.

llvm-svn: 298669

5 files changed, 12 insertions, 13 deletions

diff --git a/lld/ELF/Driver.cpp b/lld/ELF/Driver.cpp
index b0744478eea..dfd7eef4355 100644
--- a/lld/ELF/Driver.cpp
+++ b/lld/ELF/Driver.cpp
@@ -18,8 +18,8 @@
 // I don't think implicit default values are useful because they are
 // usually explicitly specified by the compiler driver. They can even
 // be harmful when you are doing cross-linking. Therefore, in LLD, we
-// simply trust the compiler driver to pass all required options to us
-// and don't try to make effort on our side.
+// simply trust the compiler driver to pass all required options and
+// don't try to make effort on our side.
 //
 //===----------------------------------------------------------------------===//
 
diff --git a/lld/ELF/LinkerScript.cpp b/lld/ELF/LinkerScript.cpp
index adb7ce862bb..73d4dea19fb 100644
--- a/lld/ELF/LinkerScript.cpp
+++ b/lld/ELF/LinkerScript.cpp
@@ -777,8 +777,8 @@ static bool shouldSkip(const BaseCommand &Cmd) {
 //
 // When the control reaches this function, Opt.Commands contains
 // output section commands for non-orphan sections only. This function
-// adds new elements for orphan sections to Opt.Commands so that all
-// sections are explicitly handled by Opt.Commands.
+// adds new elements for orphan sections so that all sections are
+// explicitly handled by Opt.Commands.
 //
 // Writer<ELFT>::sortSections has already sorted output sections.
 // What we need to do is to scan OutputSections vector and
@@ -788,7 +788,7 @@ static bool shouldSkip(const BaseCommand &Cmd) {
 //
 // There is some ambiguity as to where exactly a new entry should be
 // inserted, because Opt.Commands contains not only output section
-// commands but other types of commands such as symbol assignment
+// commands but also other types of commands such as symbol assignment
 // expressions. There's no correct answer here due to the lack of the
 // formal specification of the linker script. We use heuristics to
 // determine whether a new output command should be added before or
diff --git a/lld/ELF/SyntheticSections.h b/lld/ELF/SyntheticSections.h
index e60df2847d7..c136f35f47f 100644
--- a/lld/ELF/SyntheticSections.h
+++ b/lld/ELF/SyntheticSections.h
@@ -154,9 +154,9 @@ private:
 };
 
 // BssSection is used to reserve space for copy relocations and common symbols.
-// We create three instances of this class for .bss, .bss.rel.ro and "COMMON".
-// .bss is used for writable symbols, .bss.rel.ro is used for read-only symbols
-// and latter used for common symbols.
+// We create three instances of this class for .bss, .bss.rel.ro and "COMMON",
+// that are used for writable symbols, read-only symbols and common symbols,
+// respectively.
 class BssSection final : public SyntheticSection {
 public:
   BssSection(StringRef Name);
diff --git a/lld/ELF/Threads.h b/lld/ELF/Threads.h
index 3df9636068a..897432e69f8 100644
--- a/lld/ELF/Threads.h
+++ b/lld/ELF/Threads.h
@@ -15,7 +15,7 @@
 //
 // That said, we don't want to do "too clever" things using threads.
 // Complex multi-threaded algorithms are sometimes extremely hard to
-// justify the correctness and can easily mess up the entire design.
+// reason about and can easily mess up the entire design.
 //
 // Fortunately, when a linker links large programs (when the link time is
 // most critical), it spends most of the time to work on massive number of
@@ -34,7 +34,7 @@
 // instead of std::for_each (or a plain for loop). Because tasks are
 // completely independent from each other, we can run them in parallel
 // without any coordination between them. That's very easy to understand
-// and justify.
+// and reason about.
 //
 // For the cases such as the latter, we can use parallel algorithms to
 // deal with massive data. We have to write code for a tailored algorithm
diff --git a/lld/ELF/Writer.cpp b/lld/ELF/Writer.cpp
index 03dc358a367..83667f453e3 100644
--- a/lld/ELF/Writer.cpp
+++ b/lld/ELF/Writer.cpp
@@ -1337,9 +1337,8 @@ template <class ELFT> std::vector<PhdrEntry> Writer<ELFT>::createPhdrs() {
     AddHdr(PT_GNU_EH_FRAME, In<ELFT>::EhFrameHdr->OutSec->getPhdrFlags())
         ->add(In<ELFT>::EhFrameHdr->OutSec);
 
-  // PT_OPENBSD_RANDOMIZE specifies the location and size of a part of the
-  // memory image of the program that must be filled with random data before any
-  // code in the object is executed.
+  // PT_OPENBSD_RANDOMIZE is an OpenBSD-specific feature. That makes
+  // the dynamic linker fill the segment with random data.
   if (OutputSection *Sec = findSection(".openbsd.randomdata"))
     AddHdr(PT_OPENBSD_RANDOMIZE, Sec->getPhdrFlags())->add(Sec);