llvm-svn: 287742

There are two ways to set symbol versions. One way is to use symbol
definition file, and the other is to embed version names to symbol
names. In the latter way, symbol name is in the form of `foo@version1`
where `foo` is a real name and `version1` is a version.

We were parsing symbol names in insert(). That seems unnecessarily
too early. We can do it later after we resolve all symbols. Doing it
lazily is a good thing because it makes code easier to read
(because now we have a separate pass to parse symbol names). Also
it could slightly improve performance because if two identical symbols
have versions, we now parse them only once.

llvm-svn: 287741

Previously, we stored offsets in string tables to symbols, so
you needed to pass a string table to get a symbol name. This patch
stores const char pointers instead to eliminate the need to pass
a string table.

llvm-svn: 287737

This allows making symbols containing ADDR(section) synthetic,
and defining synthetic symbols outside SECTIONS block.

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

llvm-svn: 287090

Patch adds a filename to that error message.

I faced next error when debugged one of FreeBSD port:
error: relocation R_X86_64_PLT32 cannot refer to absolute symbol __tls_get_addr

error message was poor and this patch improves it to show the locations 
of symbol declaration and using.

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

llvm-svn: 286940

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 a lot of BumpPtrAllocators, but all these
allocators virtually have the same lifetime because they are
not freed until the linker finishes its job. This patch aggregates
them into a single allocator.

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

llvm-svn: 285452

Another step in making it easier to create symbols without an ELf_Sym.

llvm-svn: 285241

llvm-svn: 285240

All the global ones now just forward to the same constructor. This
makes it easier to construct them without creating a Elf_Sym.

llvm-svn: 285238

We used to have one allocator per file, which reduces the advantage of
using an allocator in the first place.

This is a small speed up is most cases. The largest speedup was in
1.014X in chromium no-gc. The largest slowdown was scylla at 1.003X.

llvm-svn: 285205

llvm-svn: 285149

llvm-svn: 284878

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

llvm-svn: 284758

llvm-svn: 284739

llvm-svn: 284705

In case of linking PIC and non-PIC code together and generation of a
relocatable object, all PIC symbols should have STO_MIPS_PIC flag in the
symbol table of the ouput file.

llvm-svn: 282714

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

llvm-svn: 282656

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: 280237

Given that we almost always want to handle it as DefinedRegular, just
use DefinedRegular.

llvm-svn: 280226

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

llvm-svn: 280144

This symbol can be used by the program to examine its own headers.

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

llvm-svn: 279452

Since CommonInputSection is a singleton class, we don't need
to store pointers to all DefinedCommon symbols.

llvm-svn: 277410

llvm-svn: 277023

r275711 for "speedng up symbol version handling" was committed
by misunderstanding; the benchmark number was measured with
a debug build. The number with a release build didn't actually change.
This patch removes false optimizations added in that patch.

llvm-svn: 276267

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

--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

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

llvm-svn: 274917

llvm-svn: 274909

Symbol's dtors are not called because they are allocated using
BumpPtrAllocators. So, members of std::unique_ptr type are not
freed when symbols are deallocated.

This patch is to allocate Thunks using BumpPtrAllocators.

llvm-svn: 274896

The TinyPtrVector of const Thunk<ELFT>* in InputSections.h can cause 
build failures on certain compiler/library combinations when Thunk<ELFT> 
is not a complete type or is an abstract class. Fixed by making Thunk<ELFT>
non Abstract.

type or is an abstract class 

llvm-svn: 274863