Previously, we were checking the existence of an entry symbol
too early. It was done before the linker script processor creates
symbols defined in scripts. Fixes bug 30743.

llvm-svn: 284676

We don't gc them anyway, so just use an early return in Enqueue.

llvm-svn: 284663

.ARM.exidx sections have a reverse dependency on the section they have
a SHF_LINK_ORDER dependency on. In other words a .ARM.exidx section is
live only if the executable section it describes is live. We implement
this with a reverse dependency field in InputSection.

Adding the dependency to InputSection is the simplest implementation
but it could be moved out to a separate map if it were found to decrease
performance for non ARM targets.

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

llvm-svn: 283734

llvm-svn: 283382

llvm-svn: 283173

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

llvm-svn: 282708

llvm-svn: 282663

r282444 introduced new issue, sample program below
fails to link on

assert(Piece.Live);
int main() { return 0; }
clang test.cpp -c -o out.o -g
ld.lld -flavor gnu --gc-sections out.o -o out

Problem is that .debug_info contains relocations to .debug_str:
Section (7) .rela.debug_info {
..

0xC R_X86_64_32 .debug_str 0x0
0x12 R_X86_64_32 .debug_str 0x37
..
But we do not preserve .debug_str in a right way now.

To fix this we should ignore relocations from non-allocatable sections to allocatable
to allow GC work at full power, but still should proccess relocations from non-allocatable to non-allocatable sections
as usual to mark some parts of debug sections alive to keep them so we do not end 
up with such assert when trying to access dead pieces. That looks like what gold/ld do, they do 
not strip .debug_str section from what I saw using sample provided.

Thanks to Evgeny Leviant for suggestions about how to fix this.

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

llvm-svn: 282495

This matches the gold behaviour and is important to prevent debug info
from effectively disabling gc.

llvm-svn: 282444

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

llvm-svn: 282393

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

llvm-svn: 282391

The ELF spec doesn't allow relocations to point directly to
a deduplicated COMDAT section but this unfortunately happens in
practice. Bail out early instead of crashing.

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

llvm-svn: 282197

Previously, all input files were owned by the symbol table.
Files were created at various places, such as the Driver, the lazy
symbols, or the bitcode compiler, and the ownership of new files
was transferred to the symbol table using std::unique_ptr.
All input files were then free'd when the symbol table is freed
which is on program exit.

I think we don't have to transfer ownership just to free all
instance at once on exit.

In this patch, all instances are automatically collected to a
vector and freed on exit. In this way, we no longer have to
use std::unique_ptr.

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

llvm-svn: 281425

llvm-svn: 281381

llvm-svn: 281210

This simplifies error handling as there is now only one place in the
code that needs to consider the possibility that the name is
corrupted. Before we would do it in every access.

llvm-svn: 280937

llvm-svn: 277926

Not all relocations from a .eh_frame that point to an executable
section should be ignored. In particular, the relocation finding the
personality function should not.

This is a reduction from trying to bootstrap a static lld on linux.

llvm-svn: 276329

llvm-svn: 275803

llvm-svn: 274429

llvm-svn: 270532

Previously, mergeable section's constructors did more than just
setting member variables; it split section contents into small
pieces. It is not always computationally cheap task because if
the section is a mergeable string section, it needs to scan the
entire section to split them by NUL characters.

If a section would be thrown away by GC, that cost ended up
being a waste of time. It is going to be larger problem if the
section is compressed -- the whole time to uncompress it and
split it up is going to be a waste.

Luckily, we can defer section splitting after GC. We just have
to remember which offsets are in use during GC and apply that later.
This patch implements it.

Differential Revision: http://reviews.llvm.org/D20516

llvm-svn: 270455

This patch adds Size member to SectionPiece so that getRangeAndSize
can just return a SectionPiece instead of a std::pair<SectionPiece *, uint_t>.
Also renamed the function.

llvm-svn: 270346

We were using std::pair to represents pieces of splittable section
contents. It hurt readability because "first" and "second" are not
meaningful. This patch give them names.

One more thing is that piecewise liveness information is stored to
the second element of the pair as a special value of output section
offset. It was confusing, so I defiend a new bit, "Live", in the
new struct.

llvm-svn: 270340

We have to add sections to the work list, not just mark them live.

llvm-svn: 268628

We were previously using an output offset of -1 for both GC'd and tail
merged pieces. We need to distinguish these two cases in order to filter
GC'd symbols from the symbol table -- we were previously asserting when we
asked for the VA of a symbol pointing into a dead piece, which would end
up asking the tail merging string table for an offset even though we hadn't
initialized it properly.

This patch fixes the bug by using an offset of -1 to exclusively mean GC'd
pieces, using 0 for tail merges, and distinguishing the tail merge case from
an offset of 0 by asking the output section whether it is tail merge.

Differential Revision: http://reviews.llvm.org/D19953

llvm-svn: 268604

llvm-svn: 268286

Patch implements one of suggestions from Rafael Ávila de Espíndola,
to fix segfault after section that contains personality being
garbage collected.

Suggestion was just to keep alive all non executable sections
referenced by .eh_frame.

This fixes PR27529.

Differential revision: http://reviews.llvm.org/D19656

llvm-svn: 268228

This patch implements a new design for the symbol table that stores
SymbolBodies within a memory region of the Symbol object. Symbols are mutated
by constructing SymbolBodies in place over existing SymbolBodies, rather
than by mutating pointers. As mentioned in the initial proposal [1], this
memory layout helps reduce the cache miss rate by improving memory locality.

Performance numbers:

           old(s) new(s)
Without debug info:
chrome      7.178  6.432 (-11.5%)
LLVMgold.so 0.505  0.502 (-0.5%)
clang       0.954  0.827 (-15.4%)
llvm-as     0.052  0.045 (-15.5%)
With debug info:
scylla      5.695  5.613 (-1.5%)
clang      14.396 14.143 (-1.8%)

Performance counter results show that the fewer required indirections is
indeed the cause of the improved performance. For example, when linking
chrome, stalled cycles decreases from 14,556,444,002 to 12,959,238,310, and
instructions per cycle increases from 0.78 to 0.83. We are also executing
many fewer instructions (15,516,401,933 down to 15,002,434,310), probably
because we spend less time allocating SymbolBodies.

The new mechanism by which symbols are added to the symbol table is by calling
add* functions on the SymbolTable.

In this patch, I handle local symbols by storing them inside "unparented"
SymbolBodies. This is suboptimal, but if we do want to try to avoid allocating
these SymbolBodies, we can probably do that separately.

I also removed a few members from the SymbolBody class that were only being
used to pass information from the input file to the symbol table.

This patch implements the new design for the ELF linker only. I intend to
prepare a similar patch for the COFF linker.

[1] http://lists.llvm.org/pipermail/llvm-dev/2016-April/098832.html

Differential Revision: http://reviews.llvm.org/D19752

llvm-svn: 268178

Differential Revision: http://reviews.llvm.org/D19490

llvm-svn: 267637

We were only doing it for .so and --export-dynamic, but those are not
the only ways a symbol ends up in the dynamic symbol table.

Problem diagnostic and earlier patch version by Peter Collingbourne.

llvm-svn: 267568

The fix is to handle local symbols referring to SHF_MERGE sections.

Original message:

GC entries of SHF_MERGE sections.

It is a fairly direct extension of the gc algorithm. For merge sections
instead of remembering just a live bit, we remember which offsets
were used.

This reduces the .rodata sections in chromium from 9648861 to 9477472
bytes.

llvm-svn: 267233

    This reverts commit r267164.

    Revert "Trying to fix the windows build."

    This reverts commit r267168.

Debugging a bootstrap problem.

llvm-svn: 267194

These are properties of a symbol name, rather than a particular instance
of a symbol in an object file. We can simplify the code by collecting these
properties in Symbol.

The MustBeInDynSym flag has been renamed ExportDynamic, as its semantics
have been changed to be the same as those of --dynamic-list and
--export-dynamic-symbol, which do not cause hidden symbols to be exported.

Differential Revision: http://reviews.llvm.org/D19400

llvm-svn: 267183

It is a fairly direct extension of the gc algorithm. For merge sections
instead of remembering just a live bit, we remember which offsets were
used.

This reduces the .rodata sections in chromium from 9648861 to 9477472
bytes.

llvm-svn: 267164

It turns out that this will read data from the section to properly
handle Elf_Rel implicit addends.

Sorry for the noise.

Original messages:

Try to fix Windows lld build.

Move getRelocTarget to ObjectFile.
It doesn't use anything from the InputSection.

llvm-svn: 267163

llvm\tools\lld\ELF\MarkLive.cpp(49): error C2872: 'ObjectFile': ambiguous symbol
llvm\tools\lld\elf\InputFiles.h(100): note: could be 'lld::elf::ObjectFile'
llvm\include\llvm/Object/IRObjectFile.h(26): note: or       'llvm::object::ObjectFile'
llvm\tools\lld\ELF\MarkLive.cpp(133): note: see reference to function template instantiation
    'void forEachSuccessor<ELFT>(lld::elf::InputSection<ELFT> *,
                                 std::function<void (lld::elf::InputSectionBase<ELFT> *)>)'
    being compiled with
                [ ELFT=llvm::object::ELF32LE ]
llvm\tools\lld\ELF\MarkLive.cpp(136): note: see reference to function template instantiation
    'void lld::elf::markLive<llvm::object::ELF32LE>(lld::elf::SymbolTable<llvm::object::ELF32LE> *)
    being compiled

llvm-svn: 267161

It doesn't use anything from the InputSection.

llvm-svn: 267154

llvm-svn: 267147

llvm-svn: 267081