Summary:
getFile() can return nullptr. This usually happens when Rels is empty so
the reference is never used. Still UBSAN complains.

Reviewers: rafael

Subscribers: llvm-commits

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

llvm-svn: 286937

Propagate program headers by walking the commands, not the
sections. This allows us to propagate program headers even from
sections that don't end up in the output.

Fixes pr30997.

llvm-svn: 286837

-M, --print-map Write map file on standard output
-Map MAPFILENAME Write map file
--cref	Output cross reference table

This is relative to PR30973.

Next FreeBSD ports were atm failing because of 
lack of -Map, -M and --cref:

sysutils/openipmi
emulators/adamem
devel/jwasm
net/pimd
devel/k8048
textproc/libcrm114
lang/micropython
net/mrouted
print/openprinting

After this patch all of them can be link fine.

llvm-svn: 286831

To fix pr30997 we will have to keep them a bit longer, this just
splits that part of the diff.

llvm-svn: 286827

llvm-svn: 286826

llvm-svn: 286824

llvm-svn: 286805

llvm-svn: 286804

llvm-svn: 286803

This branch was unused I believe,
as Tok can never be empty.

llvm-svn: 286802

llvm-svn: 286801

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

llvm-svn: 286799

Previously we did not support anything except "local: *", patch changes that.

Actually GNU rules of proccessing wildcards are more complex than that (http://www.airs.com/blog/archives/300):
There are 2 iteration for wildcards, at first iteration "*" wildcards are ignored and handled at second iteration.

Since we previously decided not to implement such complex rules,
I suggest solution that is implemented in this patch. So for "local: *" case nothing changes,
but if we have wildcarded locals,
they are processed before wildcarded globals. 

This should fix several FreeBSD ports, one of them is jpeg-turbo-1.5.1 and
currently blocks about 5k of ports.

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

llvm-svn: 286713

llvm-svn: 286698

Unlike gold, bfd, gas or MC we were putting exidx sections first since
they are ro.

The spec doesn't explicitly say that they must come after, but it is
definitely more convenient for the consumer, matches other producers
and matches other areas in ELF (like SHT_GROUP) where sections are
ordered in a natural way.

llvm-svn: 286659

We would create a MergeInputSection for the synthetic .comment and
crash trying to add it to a regular output section.

With this we just don't add the synthetic section with -r. That is
consistent with gold that doesn't create .note.gnu.gold-version with
-r.

llvm-svn: 286635

The functions getBitcodeTargetTriple(), isBitcodeContainingObjCCategory(),
getBitcodeProducerString() and hasGlobalValueSummary() now return errors
via their return value rather than via the diagnostic handler.

To make this work, re-implement these functions using non-member functions
so that they can be used without the LLVMContext required by BitcodeReader.

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

llvm-svn: 286623

llvm-svn: 286590

llvm-svn: 286588

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

llvm-svn: 286580

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