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

With this, "llvm-pdbdump yaml -ipi-stream" prints out an IPI stream.
Previously it crashed because it can't handle the case where IPI
stream doesn't exist.

llvm-svn: 283392

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

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

llvm-svn: 283213

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

Follow-up to r282716. Reject input files with non-zero GP0 value only in
case of relocatable object generation. In other case we can handle
arbitrary GP0 value so it does not have a sense to make the restriction
so wide.

llvm-svn: 283194

I do not fully understand how to use these classes yet, but
seems like these arguments are not used, since without them
all tests still pass. In order to simplify the situation,
I'll remove them now.

llvm-svn: 283174

llvm-svn: 283173

llvm-svn: 283101

Case was revealed by id_000010,sig_08,src_000000,op_havoc,rep_4 from PR30540.

Out implementation uses uint32 for storing section alignment value,
what seems reasonable, though if value exceeds 32 bits bounds we have
truncation and final value of 0.

Patch fixes the issue.

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

llvm-svn: 283097

llvm-svn: 282964

llvm-svn: 282945

llvm-svn: 282942

llvm-svn: 282926

This was intended to warn on a usage error of an ar command.
I was thinking that false positive would be rare because it
has two guards: it warns only when an archive file has no symbols
and contains at least one file.

Turned out that false positive would probably be not that rare.
You wouldn't intentionally create an object file that contains no
exported symbols, but with conditional compile guards, you could
create such file. If it is for a LTO build, you could create an
archive file containing such file. That means there's no way to
detect the usage error in a reliable manner.

This patch simply removes the warning.

llvm-svn: 282916

Previously, it warned on any archive file that has no symbol.
It turned out that that is too noisy.

With this patch, it warns on such archive file that contains no file.

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

llvm-svn: 282885

llvm-svn: 282851

llvm-svn: 282850

The missing case was when a merge section was only referenced from
non-alloca sections.

llvm-svn: 282847

We would crash when a non-alloca section pointed to a gced part of a
merge section.

That can happen when a C/c++ constant in put in a merge section and
debug info is present.

llvm-svn: 282845

We were implicitly creating space for the headers. That is not the
behaviour of bfd, which requires the script to use SIZEOF_HEADERS. The
difference is important for scripts that don't use SIZEOF_HEADERS and
expect the first section to be at 0.

llvm-svn: 282818