The change in D26502 splits ReaderWriter.h, which contains the APIs
into both the BitReader and BitWriter libraries, into BitcodeReader.h
and BitcodeWriter.h.

Change lld uses to the appropriate split header, removing it
completely in one case where it wasn't needed.

llvm-svn: 286568

This would trigger an assertion at runtime otherwise.

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

llvm-svn: 286562

This is forcing to use Error::success(), which is in a wide majority
of cases a lot more readable.

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

llvm-svn: 286561

llvm-svn: 286557

llvm_shutdown could write something to outs or errs,
so we need to flush them after calling llvm_shutdown.

llvm-svn: 286548

The previous code didn't make sense at all. Now an error condition
is handled with fatal(). Thanks to Mehdi for pointing out the issue.

llvm-svn: 286547

llvm-svn: 286529

Summary:
This patch adds a ".comment" section to an output. The comment
section contains the linker's version string. You can now
find out whether a binary is created by LLD or not using objdump
command like this.

  $ objdump -s -j .comment foo

  foo:     file format elf64-x86-64

  Contents of section .comment:
   0000 00474343 3a202855 62756e74 7520342e  .GCC: (Ubuntu 4.
   0010 382e342d 32756275 6e747531 7e31342e  8.4-2ubuntu1~14.
   ...
   00c0 766d2f74 72756e6b 20323835 38343629  vm/trunk 285846)
   00d0 004c696e 6b65723a 204c4c44 20342e30  .Linker: LLD 4.0
   00e0 2e302028 7472756e 6b203238 36343036  .0 (trunk 286406
   00f0 2900                                 ).

Compilers emits .comment section as well, so the output contains
both compiler and linker information.

Alternative considered:

I first tried to add a SHT_NOTE section because GNU gold does that.
A NOTE section starts with a header which contains content type.
It turned out that ld.gold sets type NT_GNU_GOLD_VERSION to their
NOTE section. So the NOTE type is only for GNU gold (surprise!)

Next, I tried to create ".linker-version" section. However, it seems
that reusing the existing ".comment" section is better because 1)
other tools already know about .comment section and is able to strip
it and 2) the result contans not only linker info but also compiler
info.

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

llvm-svn: 286496

In a non-LTO build is a nop. In a LTO build, we deallocate/destroy
managed static and this allows us to get the output of, e.g.,
-time-passes without performing a full shutdown.

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

llvm-svn: 286493

Thanks to Michael Spencer for the suggestion.

llvm-svn: 286462

Relocations are the last thing that we wore storing a raw section
pointer to and parsing on demand.

With this patch we parse it only once and store a pointer to the
actual data.

The patch also changes where we store it. It is now in
InputSectionBase. Not all sections have relocations, but most do and
this simplifies the logic. It also means that we now only support one
relocation section per section. Given that that constraint is
maintained even with -r with gold bfd and lld, I think it is OK.

llvm-svn: 286459

Though the patch was technically correct,
the only FreeBSD port (noticed atm) that tried using it was
www/mod_jk. And it seems just passed gcc option to linker by mistake:

"-Wl,-L-L/usr/local/lib -Wl,-rpath,/usr/local/lib -Wl,-fstack-protector -Wl,-fstack-protector -o mod_jk.la "

Given that it is an easy mistake to make, reverting for now.

llvm-svn: 286458

Without that FreeBSD port was failing with next confuxing error:
/usr/bin/ld: error: unknown argument: -fstack-protector

llvm-svn: 286451

llvm-svn: 286445

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

llvm-svn: 286443

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

llvm-svn: 286422

This version of addRegular is almost identical to the other except
it lacked "size" parameter.

llvm-svn: 286416

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

llvm-svn: 286406

llvm-svn: 286405

llvm-svn: 286401

Previously, we have both input and output section for .MIPS.abiflags.
Now we have only one class for .MIPS.abiflags, which is MipsAbiFlagsSection.
This class is a synthetic input section.

.MIPS.abiflags sections are handled as regular sections until
the control reaches Writer. Writer then aggregates all sections
whose type is SHT_MIPS_ABIFLAGS to create a single synthesized
input section. The synthesized section is then processed normally
as if it came from an input file.

llvm-svn: 286398

Previously, we have both input and output sections for .reginfo and
.MIPS.options. Now for each such sections we have one synthetic input
sections: MipsReginfoSection and MipsOptionsSection respectively.

Both sections are handled as regular sections until the control reaches
Writer. Writer then aggregates all sections whose type is SHT_MIPS_REGINFO
or SHT_MIPS_OPTIONS to create a single synthesized input section. In that
moment Writer also save GP0 value to the MipsGp0 field of the corresponding
ObjectFile. This value required for R_MIPS_GPREL16 and R_MIPS_GPREL32
relocations calculation.

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

llvm-svn: 286397

It was quite confusing that it had SectionKind of Regular, but was not
actually a InputSection.

llvm-svn: 286379

During link of devel/chrpath (FreeBSD port), found next issue:
/usr/bin/ld: error: unclosed comment in a linker script
/usr/bin/ld: error: line 1: unknown directive: �
/usr/bin/ld: error: ��

Problem was not obvious and the reason was that we did not accept
the separate form of -R. While invocation line contained it:
cc -Wl,-R /usr/local/lib -o prog prog.c

CPIO file produced contained /usr/local/lib file. 
Which looks because of reasons above
contained inside the content of whole lib folder, 
and it then was passed as an input and
proccessed as linker script.

llvm-svn: 286378

llvm-svn: 286370

    
The ARM 32 and 64-bit ABI does not use 0 for undefined weak references
that are used in PC relative relocations. In particular:
- A branch relocation to an undefined weak resolves to the next
  instruction. Effectively making the branch a no-op
- In all other cases the symbol resolves to the place so that S + A - P
  resolves to A.

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

llvm-svn: 286353

llvm-svn: 286348

This is similar to what was done for InputSection.

With this the various fields are stored in host order and only
converted to target order when writing.

llvm-svn: 286327

All tests pass without the first parameter, so I guess we don't need it.

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

llvm-svn: 286287

llvm-svn: 286286

llvm-svn: 286282

Avoids having to skip them multiple times.

llvm-svn: 286261

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

llvm-svn: 286244

llvm-svn: 286242

Thanks to Malcolm Parsons who pointed on that.

llvm-svn: 286239

We can just use a regular InputSection.

llvm-svn: 286237

This reverts commit r286100.

This saves 8 bytes of every InputSection.

llvm-svn: 286235

With the current infrastructure it can be just an ordinary
InputSection like the real .bss sections.

llvm-svn: 286234