// 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.
//
//===----------------------------------------------------------------------===//
//
// 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
//
// 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
};
// 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);
//
// 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
// 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
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);