llvm-svn: 299208

llvm-svn: 299184

http://bb.pgr.jp/builders/i686-mingw32-RA-on-linux/builds/25073/steps/build_llvmclang/logs/stdio

llvm-svn: 299171

Introduce symbol table data structures that can be potentially written to
disk, have the LTO library build those data structures using temporarily
constructed modules and redirect the LTO library implementation to go through
those data structures. This allows us to remove the LLVMContext and Modules
owned by InputFile.

With this change I measured a peak memory consumption decrease from 5.4GB to
2.8GB in a no-op incremental ThinLTO link of Chromium on Linux. The impact on
memory consumption is larger in COFF linkers where we are currently forced
to materialize all metadata in order to read linker options. Peak memory
consumption linking a large piece of Chromium for Windows with full LTO and
debug info decreases from >64GB (OOM) to 15GB.

Part of PR27551.

Differential Revision: https://reviews.llvm.org/D31364

llvm-svn: 299168

llvm-svn: 299128

llvm-svn: 299115

This change is to improve consistency with other files.

llvm-svn: 299110

Previously, undefined symbol errors are one line like this
and wasn't easy to read.

  /ssd/clang/bin/ld.lld: error: /ssd/llvm-project/lld/ELF/Writer.cpp:207: undefined symbol 'lld::elf::EhFrameSection<llvm::object::ELFType<(llvm::support::endianness)0, true> >::addSection(lld::elf::InputSectionBase*)'

This patch make it more structured like this.

  bin/ld.lld: error: undefined symbol: lld::elf::EhFrameSection<llvm::object::ELFType<(llvm::support::endianness)0, true>
  >>> Referenced by Writer.cpp:207 (/ssd/llvm-project/lld/ELF/Writer.cpp:207)
  >>>               Writer.cpp.o in archive lib/liblldELF.a

Discussion thread:
http://lists.llvm.org/pipermail/llvm-dev/2017-March/111459.html

Differential Revision: https://reviews.llvm.org/D31481

llvm-svn: 299097

llvm-svn: 299025

This reverts commit because this really shouldn't happen unless
there's a bug in LLD.

llvm-svn: 299021

This patch changes GnuHashTableSection implementation
to avoid depend on uintX_t and other ELFT stuff, reducing amount of 
changes for following patch(es).

Differential revision: https://reviews.llvm.org/D31184

llvm-svn: 298998

llvm-svn: 298971

uint64_t is simpler and less error-prone than target or host-dependent types.

llvm-svn: 298969

If a function takes a size and an alignment, we usually pass them
in that order instead of the reverse order.

llvm-svn: 298968

This is not an original comment but taken from gdb man page, so
a pointer to the original document should suffice.

llvm-svn: 298964

This makes the predicates independent of the flag representation
and makes the code a little easier to read.

llvm-svn: 298951

.gnu.hash happen to contain only 32-bit integers for 32-bit arch,
but the section contents are not uniform array members, so setting
entsize doesn't make much sense. This behavior seems to have been
blindly copied from GNU linkers.

llvm-svn: 298934

llvm-svn: 298829

This patch calls getAddend on a relocation only when the relocation is RELA.
That doesn't really improve runtime performance but should improve
readability as the code now matches the function description.

llvm-svn: 298828

llvm-svn: 298821

llvm-svn: 298818

Previously, computeAddend had many parameters but most of them were
used only for MIPS. The MIPS ABI is too odd that I don't want to mix
it into the regular code path. Splitting the function into non-MIPS
and MIPS parts makes the regular code path easy to follow.

llvm-svn: 298817

llvm-svn: 298815

llvm-svn: 298814

llvm-svn: 298797

llvm-svn: 298796

llvm-svn: 298795

llvm-svn: 298794

llvm-svn: 298793

llvm-svn: 298792

llvm-svn: 298790

llvm-svn: 298789

llvm-svn: 298788

llvm-svn: 298787

C is short for Chunk, but we are no longer using that term.
RI is probably short for relocation iterator, but this is not an interator.

llvm-svn: 298786

Previously, relocation offsets are recalculated for .eh_frame sections
inside the main loop, and that messed up the main loop. This patch
separates that logic into a dedicated class.

llvm-svn: 298785

I just didn't know that raw_fd_ostream has has_colors() function.

llvm-svn: 298749

llvm-svn: 298748

llvm-svn: 298675

The original code is a big `if` and `else` which ends with `continue`
like this:

  if (cond) {
    ...
    // fall through
  } else {
    ...
    continue;
  }

This patch rewrites it with the following.

  if (!cond) {
    ...
    continue;
  }
  ...

llvm-svn: 298672