This allows making symbols containing ADDR(section) synthetic,
and defining synthetic symbols outside SECTIONS block.

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

llvm-svn: 287090

Patch improves message to show locations for
"can't create dynamic relocation" error.

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

llvm-svn: 287086

llvm-svn: 287082

llvm-svn: 287072

The code to handle symbol versions is getting tricky and hard to
understand, so it is probably time to simplify it. This patch does
the following.

 - Add `DemangledSyms` variable to SymbolTable so that we don't
   need to pass it around to findDemangled.
 - Define `initDemangledSyms` to initialize the variable lazily.
 - hasExternCpp is removed because we no longer have to initialize
   the map eagerly.
 - scanScriptVersion is split.
 - Comments are updated.

llvm-svn: 287002

In this file, `sym` was used for both SymbolBody and SymbolVersion
although the two are completely different.

llvm-svn: 286992

We had two functions with the same name to read completely different
things. That was confusing.

llvm-svn: 286991

llvm-svn: 286955

This patch introduces the following changes:
- DynamicSection now inherits InputSection<ELFT> and was moved
  to SyntheticSections.h/.cpp.
- Link and Entsize fields of DynamicSection are propagated to 
  its output section
- In<ELFT>::SyntheticSections was removed.
- Finalization of synthetic sections was removed from 
  OutputSection<ELFT>::finalize. Now finalizeSyntheticSections is
  used instead.

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

llvm-svn: 286950

This patch stops creating symbols like __ehdr_start, 
_end/_etext_edata,__tls_get_addr when using -r.

This fixes PR30984.

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

llvm-svn: 286941

Patch adds a filename to that error message.

I faced next error when debugged one of FreeBSD port:
error: relocation R_X86_64_PLT32 cannot refer to absolute symbol __tls_get_addr

error message was poor and this patch improves it to show the locations 
of symbol declaration and using.

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

llvm-svn: 286940

Found this when tried to link lang/ccl FreeBSD port.
Issue is very close to D23201.
This is the reason of lang/ccl port link fail.

GNU assembler 2.17.50 [FreeBSD] 2007-07-03 could generate broken objects,
where notype symbols are associated with symtab:
...
[ 9] .symtab           SYMTAB           0000000000000000  00003c78
     0000000000006858  0000000000000018          10   803     8
...
192: 000000000000000d     0 NOTYPE  LOCAL  DEFAULT    9 _cons_org

Patch allows to handle such objects.

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

llvm-svn: 286939

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