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

llvm-svn: 287675

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

llvm-svn: 287554

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

llvm-svn: 287549

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

llvm-svn: 287526

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

llvm-svn: 287346

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

llvm-svn: 287326

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

llvm-svn: 287322

MergeOutputSection class was a bit hard to use because it provdes
a series of finalize functions that have to be called in a right way
at a right time. It also intereacted with MergeInputSection, and the
logic was somewhat entangled between the two classes.

This patch simplifies it by providing only one finalize function.
Now, all you have to do is to call MergeOutputSection::finalize
when you have added all sections to the output section. Then, it
internally merges strings and initliazes StringPiece objects.
I think this is much easier to understand.

This patch also adds comments.

llvm-svn: 287314

llvm-svn: 287218

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

llvm-svn: 287216

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

llvm-svn: 287092

This patch introduces the following changes:
- DynamicSection now inherits InputSection<ELFT> and was moved
  to SyntheticSections.h/.cpp.
- Link and Entsize fields of DynamicSection are propagated to 
  its output section
- In<ELFT>::SyntheticSections was removed.
- Finalization of synthetic sections was removed from 
  OutputSection<ELFT>::finalize. Now finalizeSyntheticSections is
  used instead.

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

llvm-svn: 286950

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

llvm-svn: 286799

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

llvm-svn: 286580

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

llvm-svn: 286443

Patch allows to pass a symbols file to linker.
LLD will map symbols to sections and sort sections
in output according to symbol ordering file.

That can help to reduce the startup time and/or
amount of pagefaults during startup.

Also, interesting benchmark result was produced by Rafael Espíndola. 
After applying the symbols file for clang he timed compiling 
X86MCTargetDesc.ii to an object file.  

The page faults went from just
56,988 to 56,946 since most faults are not in the binary.
Running time went from 4.403053515 to 4.178112244. 
The speedup seems to be because of better cache
locality.

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

llvm-svn: 286440

The disadvantage is that we use uint64_t instad of uint32_t for some
value in 32 bit files. The advantage is a substantially simpler code,
faster builds and less code duplication.

llvm-svn: 286414

Previously, we have both input and output section for .MIPS.abiflags.
Now we have only one class for .MIPS.abiflags, which is MipsAbiFlagsSection.
This class is a synthetic input section.

.MIPS.abiflags sections are handled as regular sections until
the control reaches Writer. Writer then aggregates all sections
whose type is SHT_MIPS_ABIFLAGS to create a single synthesized
input section. The synthesized section is then processed normally
as if it came from an input file.

llvm-svn: 286398

Previously, we have both input and output sections for .reginfo and
.MIPS.options. Now for each such sections we have one synthetic input
sections: MipsReginfoSection and MipsOptionsSection respectively.

Both sections are handled as regular sections until the control reaches
Writer. Writer then aggregates all sections whose type is SHT_MIPS_REGINFO
or SHT_MIPS_OPTIONS to create a single synthesized input section. In that
moment Writer also save GP0 value to the MipsGp0 field of the corresponding
ObjectFile. This value required for R_MIPS_GPREL16 and R_MIPS_GPREL32
relocations calculation.

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

llvm-svn: 286397

This is similar to what was done for InputSection.

With this the various fields are stored in host order and only
converted to target order when writing.

llvm-svn: 286327

llvm-svn: 286286

llvm-svn: 285996

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

llvm-svn: 285851

Previously, we added strings from DynamicSection::finalize().
It was a bit tricky because finalize() is supposed to fix the final
size of the section, but adding new strings would change the size of
.dynstr section. So there was a dependency between finalize functions
of .dynamic and .dynstr.

However, I noticed that we can elimiante the dependency by simply
add strings early; we don't have to do that in finalize() but can do
from DynamicSection's ctor.

This patch defines a new function, DynamicSection::addEntries, to
add .dynamic entries that doesn't depend on other sections.

llvm-svn: 285784

llvm-svn: 285764

llvm-svn: 285763

We are going to have many more classes for linker-synthesized
input sections, so it's worth to be added to a separate file
than to the file for regular input sections.

llvm-svn: 285740

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

llvm-svn: 285682

Some MIPS relocations used to access GOT entries are able to manipulate
16-bit index. The other ones like R_MIPS_CALL_HI16/LO16 can handle
32-bit indexes. 16-bit relocations are generated by default. The 32-bit
relocations are generated by -mxgot flag passed to compiler. Usually
these relocation are not mixed in the same code but files like crt*.o
contain 16-bit relocations so even if all "user's" code compiled with
-mxgot flag a few 16-bit relocations might come to the linking phase.

Now LLD does not differentiate local GOT entries accessed via a 16-bit
and 32-bit indexes. That might lead to relocation's overflow if 16-bit
entries are allocated to far from the beginning of the GOT.

The patch introduces new "part" of MIPS GOT dedicated to the local GOT
entries accessed by 32-bit relocations. That allows to put local GOT
entries accessed via a 16-bit index first and escape relocation's overflow.

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

llvm-svn: 284809

In this patch partial gdb_index section is created. 
For costructing the .gdb_index section 6 steps should be performed (details are in
SplitDebugInfo.cpp file header), this patch do first 3:

Creates proper section header.
Fills list of compilation units.
Types CU list area is not supposed to be supported, so it is ignored and therefore
can be treated as implemented either.

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

llvm-svn: 284708

llvm-svn: 284705

Use size_t instead of ELFT::uint for the string table offset. If the
linker is built 32-bit, it can't write an output file larger than 2GB.
Other code in this area uses size_t as well.

llvm-svn: 284680

llvm-svn: 284670

llvm-svn: 284614

Summary:
Reclaiming the name 'CachedHashString' will let us add a type with that
name that owns its value.

Reviewers: timshen

Subscribers: llvm-commits

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

llvm-svn: 284434

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

llvm-svn: 283429

This spreads out computing the hash and using it in a hash table. The
speedups are:

firefox
  master 6.811232891
  patch  6.559280249 1.03841162939x faster
chromium
  master 4.369323666
  patch  4.33171853 1.00868134338x faster
chromium fast
  master 1.856679971
  patch  1.850617741 1.00327578725x faster
the gold plugin
  master 0.32917962
  patch  0.325711944 1.01064645023x faster
clang
  master 0.558015452
  patch  0.550284165 1.01404962652x faster
llvm-as
  master 0.032563515
  patch  0.032152077 1.01279662275x faster
the gold plugin fsds
  master 0.356221362
  patch  0.352772162 1.00977741549x faster
clang fsds
  master 0.635096494
  patch  0.627249229 1.01251060127x faster
llvm-as fsds
  master 0.030183188
  patch  0.029889544 1.00982430511x faster
scylla
  master 3.071448906
  patch  2.938484138 1.04524944215x faster

This seems to be because we don't stall as much. When linking firefox
stalled-cycles-frontend goes from 57.56% to 55.55%.

With -O2 the difference is even more significant since we avoid
recomputing the hash. For firefox we go from 9.990295265 to
 9.149627521 seconds (1.09x faster).

llvm-svn: 283367

If we two sections reside in the same PT_LOAD segment,
we compute second section using the following formula:
Off2 = Off1 + VA2 - VA1. This allows OS kernel allocating
sections correctly when loading an image.

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

llvm-svn: 282705

This also fixes the linker script accounting for the ELF header in
some places but not in others.

llvm-svn: 282173

It is substantially faster by processing 8 bytes at a time.

llvm-svn: 281454