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

Object files compiled with cl.exe /GL contain intermediate code for LTO.
We can't (and don't want to) interpret such code, but we should print
out a user-friendly error message.

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

llvm-svn: 286921

Summary:
getInputSections returns std::vector by value and ArrayRef
pointed to destroyed temporarily.

Reviewers: ruiu

Subscribers: llvm-commits

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

llvm-svn: 286880

I don't really understand what is failing on lld-x86_64-darwin13 bot,
but this patch should at least reduces the number of moving parts.

llvm-svn: 286876

Pointed out by Rafael!

llvm-svn: 286857

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

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

llvm-svn: 286800

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

llvm-svn: 286698

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

llvm-svn: 286684

llvm-svn: 286666

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

Pointed out by Davide.

llvm-svn: 286649

It was non-obvious that a CHECK was not matching the following section.

llvm-svn: 286643

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

https://reviews.llvm.org/D26526

llvm-svn: 286598

llvm-svn: 286590

Patch replaces forward slashes with backward inside response.txt

This is https://llvm.org/bugs/show_bug.cgi?id=30951.

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

llvm-svn: 286589

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

This matches link.exe behaviour.

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

llvm-svn: 286553

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