llvm-svn: 283910

This part was splitted from D25016.

When sh_info value was set in the way that non-local symbol was treated as local, lld
was asserting, patch fixes that.

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

llvm-svn: 283859

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

llvm-svn: 283817

Before the default was whatever number hardware_concurrency() returned.
Users can specify the number of threads via --lto-jobs=X option.

llvm-svn: 283787

llvm-svn: 283786

Sometimes the very first PT_LOAD segment, created by lld, can be empty. 
This happens when (all conditions met):

- Linker script is used
- First section in ELF image is not RO
- Not enough space for program headers.

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

llvm-svn: 283760

llvm-svn: 283742

Recommit r283733 "[ELF] - Do not crash if common symbol alignment set to value greater than UINT32_MAX.

With fix: commit changes from InputFiles.cpp too.

Original commit message:
We have following code in lld, that truncates the alignment value to 32 bit. Big alignment in this case
may give result 0 and crash later.

template <class ELFT>
CommonInputSection<ELFT>::CommonInputSection(std::vector<DefinedCommon *> Syms)
    : InputSection<ELFT>(nullptr, &Hdr, "") {
....
  for (DefinedCommon *Sym : Syms) {
    this->Alignment = std::max<uintX_t>(this->Alignment, Sym->Alignment);
...
  }
}

Patch fixes the issue.

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

llvm-svn: 283738

llvm-svn: 283735

.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

Absolute local symbols with name staring from ".L" were reason of crash.
The same could happen when using some broken inputs found by AFL.

Patch fixes that.

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

llvm-svn: 283731

The .ARM.exidx sections contain a table. Each entry has two fields:
- PREL31 offset to the function the table entry describes
- Action to take, either cantunwind, inline unwind, or PREL31 offset to
  .ARM.extab section

The table entries must be sorted in order of the virtual addresses the
first entry of the table describes. Traditionally this is implemented by
the SHF_LINK_ORDER dependency. Instead of implementing this directly we
sort the table entries post relocation. 

The .ARM.exidx OutputSection is described by the PT_ARM_EXIDX program
header

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

llvm-svn: 283730

Also use uint64_t instead of uintX_t so that you don't have to
think about two different cases to verify that the code is correct.

llvm-svn: 283585

When sh_info of sumbol table value was set to zero, lld was asserting.

Patch fixes the issue.

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

llvm-svn: 283562

llvm-svn: 283556

I found that this check still may be useful in some cases.
At fact since we use uint32_t alignment, then maximum value
that is valid for us is 0x80000000. But some broken files,
for example file from testcase may have greater value.
Because of that offset calculation overflow and crash happens.

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

llvm-svn: 283544

Previously if sh_size of dynamic section was broken,
lld may crash. Or even may not crash if used 32 bits host.
(then value may be truncated to 32 bits when doing pointer arithmetic 
and could be just zero).
Patch fixes the issue.

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

llvm-svn: 283533

createELFObj() may call error(...), for example when file is too short.
In that case header is not set and following line lead to crash:

EMachine = ELFObj.getHeader()->e_machine;

Patch fixes the issue.

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

llvm-svn: 283532

llvm-svn: 283488

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

llvm-svn: 283431

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

llvm-svn: 283429

This patch makes the check for null section stricter, 
so it is only allowed for STT_SECTION symbols now.

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

llvm-svn: 283426

llvm-svn: 283382

llvm-svn: 283372

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

It is pretty easy to get the data from the InputSection, so we don't
have to store it.

This opens the way for storing the hash instead.

llvm-svn: 283357

llvm-svn: 283340

llvm-svn: 283328

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

llvm-svn: 283307

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

llvm-svn: 283305

Do not merge sections if generating a relocatable object. It makes
the code simpler because we do not need to update relocations addends
to reflect changes introduced by merging. Instead of that we write
such "merge" sections into separate OutputSections and keep SHF_MERGE
/ SHF_STRINGS flags and sh_entsize value to be able to perform merging
later during a final linking.

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

llvm-svn: 283300

llvm-svn: 283267

llvm-svn: 283229

If we have input without object files, for example if we have only .so
code crashes in checkFlags(), getPicFlags(), getArchFlags() functions.

Patch fixes the issue.

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

llvm-svn: 283226

This conforms to GNU ld/gold behavior and fixes crash in case
excluded section also has associated relocation section

llvm-svn: 283214

Previously lld would hang in infinite loop in this case,
patch fixes the issue. Object was found during AFL run.

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

llvm-svn: 283208

Relative to PR30540.

If .symtab has invalid type in elf, no bodies are created and any relocation
that tries to access them will fail.
The same can happen if symbol index is just incorrect.

This was revealed by "id_000005,sig_11,src_000000,op_flip2,pos_420"

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

llvm-svn: 283201

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

llvm-svn: 283200

id_000021,sig_11,src_000002,op_flip1,pos_92 from PR30540

does not have TLS sections, but type
of one of the symbol is broken and set to STT_TLS,
what resulted in a crash. Patch fixes crash.

DIfferential revision: https://reviews.llvm.org/D25083

llvm-svn: 283198

Testcase contains a common symbol with zero alignment,
previously lld would crash, patch fixes that.

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

llvm-svn: 283197