In compare with D30458, this makes Bss/BssRelRo to be pure
synthetic sections.

That removes CopyRelSection class completely, making
Bss/BssRelRo to be just regular synthetics.

SharedSymbols involved in creating copy relocations are
converted to DefinedRegular, what also simplifies things.

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

llvm-svn: 297008

Prior to MSVC 2015 we had to manually include this header any
time we were going to include <thread> or <future> due to a
bug in MSVC's STL implementation.  This has been fixed in MSVC
for some time now, and we require VS 2015 minimum, so we can
remove this across all subprojects.

llvm-svn: 296906

After several smaller patches to get most of the core improvements
finished up, this patch is a straight move and header fixup of
the source.

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

llvm-svn: 296810

This is consistent with rest of the file and opens the way for a
relocation keeping multiple sections alive.

llvm-svn: 296788

llvm-svn: 296786

llvm-svn: 296773

Previously it would not catch if exact symbol name
matching would change behavior to pattern matching.

llvm-svn: 296740

llvm-svn: 296739

llvm-svn: 296728

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

llvm-svn: 296726

We were not gcing any section whose name was a C identifier. Both gold
and bfd only keep those if they are used.

To avoid having to create the __start/__stop symbols early or doing
string lookups in resolvedReloc, this patch just looks for undefined
symbols __start/__stop to decide if a section is needed or not.

llvm-svn: 296723

llvm-svn: 296703

This patch adds an option named --thinlto-cache-dir, which specifies the
path to a directory in which to cache native object files for ThinLTO
incremental builds.

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

llvm-svn: 296702

That class had three member functions, and all of them are just reader
methods that did not depend on class members, so they can be just non-
member functions.

Probably we should reorganize the functions themselves because their
return types doesn't make much sense to me, but for now I just moved
these functions out of the class.

llvm-svn: 296700

llvm-svn: 296695

llvm-svn: 296694

llvm-svn: 296689

llvm-svn: 296688

GdbIndexBuilder class inherited LoadedObjectInfo, but that's not necessary.

llvm-svn: 296687

llvm-svn: 296686

llvm-svn: 296680

Looks like .gdb.index and its support classes do things that they don't
have to or shouldn't do do. This patch addresses one of these issues.

GdbHashTab class is a hash table class. Just like other in-memory hash
tables, that incrementally updates its internal data and resizes buckets
as new elements are added so that key lookup is always fast.
But that is completely not necessary.

Unlike debuggers, we only produce hash tables for .gdb.index and
never read them. So incrementally updating a hash table in memory is
just a waste of resource and complicates the code. What we should
do is to accumulate symbols and then create the final hash table
at once.

llvm-svn: 296678

llvm-svn: 296650

llvm-svn: 296620

llvm-svn: 296619

In many places we reset Size to 0 before calling assignOffsets()
manually. Sometimes we don't do that. 
It looks we can just always do that inside.

Previous code had:
template <class ELFT> void OutputSection::assignOffsets() {
  uint64_t Off = Size;

And tests feels fine with Off = 0. 
I think Off = Size make no sence.

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

llvm-svn: 296609

r296570 intorduced crash revealed by 
gnu-hash-table.s which crashed for me.

Reason was use of uninitialized NBuckets variable.

llvm-svn: 296597

llvm-svn: 296586

Thanks to Rafael for helping to dig down into what we're really trying
to communicate here.

llvm-svn: 296580

Each input section knows its sh_entsize value, so we can set output
section's sh_entsize based on input sections values.

llvm-svn: 296577

This implementation is probably slightly inefficient than before,
but that should be negligible because this is not a performance-
critical pass.

llvm-svn: 296570

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

llvm-svn: 296542

Previously, LLD merged all read-only sections. So the following
program prints out "true" if -icf=all is specified.

  static const int foo = 1;
  static const int bar = 1;
  int main() { printf("%s\n", &foo == &bar ? "true" : "false"); }

This is somewhat counter-intuitive, and it actually caused nasty issues.
One example is https://bugs.chromium.org/p/chromium/issues/detail?id=682773#c24.

This patch changes the way how it works. Now ICF merges only functions
(i.e. executable sections).

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

llvm-svn: 296534

llvm-svn: 296529

llvm-svn: 296511

We converted them before, but there were a few remaining occurrences.

llvm-svn: 296510

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

llvm-svn: 296508

llvm-svn: 296507

I do not fully understand why we had these values in the tests, but
the new value matches what ld.bfd and ld.gold set, so I guess that
was just a mistake.

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

llvm-svn: 296505

This reverts commit r296378.

I am pretty sure this is incorrect. In particular, for just

        .cfi_startproc
        nop
        .cfi_endproc

We now add an extra 4 zeros that neither bfd nor gold add.

llvm-svn: 296503