but things happened to work on some platforms prior to r276133. This
should be the complete set (I hope).

llvm-svn: 276155

We will need to do something like this to support range extension
thunks since that process is iterative.

Doing this also has the advantage that when doing the regular
relocation scan the offset in the output section is known and we can
just store that. This reduces the number of times we have to run
getOffset and I think will allow a more specialized .eh_frame
representation.

By itself this is already a performance win.

firefox
  master 7.295045737
  patch  7.209466989 0.98826892235
chromium
  master 4.531254468
  patch  4.509221804 0.995137623774
chromium fast
  master 1.836928973
  patch  1.823805241 0.992855612714
the gold plugin
  master 0.379768791
  patch  0.380043405 1.00072310839
clang
  master 0.642698284
  patch  0.642215663 0.999249070657
llvm-as
  master 0.036665467
  patch  0.036456225 0.994293213284
the gold plugin fsds
  master 0.40395817
  patch  0.404384555 1.0010555177
clang fsds
  master 0.722045545
  patch  0.720946135 0.998477367518
llvm-as fsds
  master 0.03292646
  patch  0.032759965 0.994943428477
scylla
  master 3.427376378
  patch  3.368316181 0.98276810292

llvm-svn: 276146

Thanks to George Rimar for finding the problem.

llvm-svn: 276144

This patch simplifies output section management by making
Factory class have ownership of sections that creates.

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

llvm-svn: 276141

Previously it was harder to read and also has a error:
command kind was not checked.

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

llvm-svn: 276137

llvm-svn: 276133

llvm-svn: 276126

- R_ARM_TLS_LDM32
- R_ARM_TLS_LDO32

The local dynamic implementation and tests follows the same model as 
the other ARM TLS models. The R_ARM_TLS_LDO32 is implemented as R_ABS 
expr type as the getVA() for a TLS symbol will return the offset from the 
start of the TLS block.

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

llvm-svn: 276123

llvm-svn: 276121

Under MSVS 2015 I observed integral constant overflow warning when aggregate initialization was used
to init the bit field. Patch fixes that.

llvm-svn: 276118

In here we are iterating relocations in order, so we can do the same
with the pieces of .eh_frame and avoid a binary search.

The link times I got with this patch were:

firefox
  master 7.22977811
  patch  7.141041442 0.987726225252
chromium
  master 4.478966851
  patch  4.506602207 1.00617002914
chromium fast
  master 1.894713371
  patch  1.866446889 0.98508139414
the gold plugin
  master 0.386193907
  patch  0.382374918 0.990111213743
clang
  master 0.654849589
  patch  0.647899815 0.989387220949
llvm-as
  master 0.037212718
  patch  0.036858172 0.990472450843
the gold plugin fsds
  master 0.410876711
  patch  0.407418613 0.991583611562
clang fsds
  master 0.734623069
  patch  0.728237526 0.991307728726
llvm-as fsds
  master 0.033446197
  patch  0.03302833 0.987506292569
scylla
  master 3.38134402
  patch  3.414188846 1.00971354166

llvm-svn: 276108

    
Add relocations and identification functions for the Initial Exec
and Global Dynamic TLS model defined in Addenda to, and Errata in,
the ABI for the ARM Architecture.
    
ARM uses variant 1 of the thread local storage data
structures as defined in ELF Handling for Thread-Local Storage.
    
The "experimental" descriptor based model that can be selected in
gcc, but not clang with -mtls-dialect=gnu2 is not supported.
    
The relocations R_ARM_TLS_LE12 and R_ARM_TLS_IE12GP are not
supported, I know of no ARM Toolchain that supports these relocations
as they limit the size of the TLS block.
    
No code relaxation is supported as the standard ARM TLS model puts
the relocations on literal data.
    
Support for the local dynamic model will come in a follow up patch.

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

llvm-svn: 276095

llvm-svn: 275972

llvm-svn: 275965

llvm-svn: 275961

llvm-svn: 275959

And make it easier to spot code going dead by using elf::.

llvm-svn: 275858

llvm-svn: 275847

The 3.9 release are on the 3.9 branch.

llvm-svn: 275845

llvm-svn: 275803

In the last patch for --trace-symbol, I introduced a new symbol type
PlaceholderKind and store it to SymVector storage. It made all code
that iterates over SymVector to recognize and skip PlaceholderKind
symbols. I found that that's annoying.

In this patch, I removed PlaceholderKind and stop storing them to SymVector.
Now the information whether a symbol is being watched by --trace-symbol
is stored to the Symtab hash table.

llvm-svn: 275747

SymVector contains all symbols, so we can iterate either Symtab or SymVector
to visit all symbols. Iterating over SymVector makes the next change for
--trace-symbol possible.

llvm-svn: 275746

llvm-svn: 275728

llvm-svn: 275724

--trace-symbol is a command line option to watch a symbol.
Previosly, we looked up a hash table for a new symbol if the
option is given. Any code that looks up a hash table for each
symbol is expensive because the linker handles a lot of symbols.
In our design, we look up a hash table strictly only once
for a symbol, so --trace-symbol was an exception.

This patch improves efficiency of the option by merging the
hash table into the symbol table.

Instead of looking up a separate hash table with a string,
this patch sets `Traced` flag to symbols specified by --trace-symbol.
So, if you insert a symbol and get a symbol with `Traced` flag on,
you know that you need to print out a log message for the symbol.
This is nearly zero cost.

llvm-svn: 275716

llvm-svn: 275715

llvm-svn: 275714

Previously, there was no way to get a file name for a DefinedCommon
symbol. This patch adds it.

llvm-svn: 275712

Versions can be assigned to symbols in two different ways.
One is the usual version scripts, and the other is special
symbol suffix '@'. If a symbol contains '@', the string after
that is considered to specify a version name.

Previously, we look for '@' for all symbols.

Anything that works on every symbol can be expensive because
the linker has to handle a lot of symbols. The search for '@'
was not an exception.

In this patch, I made two optimizations.

The first optimization is to handle '@' only when at least one
version is defined. If no versions are defined, no versions can
be assigned to any symbols, so it's waste of time to search for '@'.

The second optimization is to scan only suffixes of symbol names
instead of entire symbol names. Symbol names can be very long, but
symbol versions are usually short, so scanning entire symbol names
is waste of time, too.

There are some error cases which we no longer be able to detect
with this patch. I don't think it's a major drawback because they
are minor errors. Speed is more important.

This change improves LLD with debug info self-link time from
6.6993 seconds to 6.3426 seconds (or -5.3%).

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

llvm-svn: 275711

Previously, each subclass of SymbolBody had a pointer to a source
file from which it was created. So, there was no single way to get
a source file for a symbol. We had getSourceFile<ELFT>(), but the
function was a bit inconvenient as it's a template.

This patch makes SymbolBody have a pointer to a source file.
If a symbol is not created from a file, the pointer has a nullptr.

llvm-svn: 275701

We should use CHECK-NOT instead.

llvm-svn: 275700

llvm-svn: 275695

llvm-svn: 275694

llvm-svn: 275693

llvm-svn: 275692

I think 
# REQUIRES: shell 
is required instead of 
# XFAIL: win32

llvm-svn: 275683

BSD toolchain contains a bug:
https://sourceforge.net/p/elftoolchain/tickets/491/

In short demangler works differently, fix was to update the testcase.
It should fix the FreeBSD bot failture:
http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/19432/steps/test_lld/logs/stdio

Original commit message was:
[ELF] - Implement extern "c++" version script tag

Patch implements 'extern' version script tag.
Currently only values in quotes(") are supported.

Matching of externs is performed in the same pass as exact match of globals.

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

llvm-svn: 275682

llvm-svn: 275675

SymbolVersions sounds like it had versions for a symbol, so rename it.

llvm-svn: 275674

The identifier `Version` was used too often in the code to handle
symbol versions. The struct that contains version definitions is
named `Version`. Local variables for version ID are named `Version`.
Local varaible for version string are named `Version`.

This patch give them different names.

llvm-svn: 275673