Commit Graph

366 Commits

Author SHA1 Message Date
Sean Fertile f60cb34c91 [PPC64] Thread-local storage general-dynamic to initial-exec relaxation.
Patch adds support for relaxing the general-dynamic tls sequence to
initial-exec.

the relaxation performs the following transformation:
addis r3, r2, x@got@tlsgd@ha --> addis r3, r2, x@got@tprel@ha
addi r3, r3, x@got@tlsgd@l   --> ld r3, x@got@tprel@l(r3)
bl __tls_get_addr(x@tlsgd)   --> nop
nop                          --> add r3, r3, r13

and instead of emitting a DTPMOD64/DTPREL64 pair for x, we emit a single
R_PPC64_TPREL64.

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

llvm-svn: 335651
2018-06-26 19:38:18 +00:00
Fangrui Song 4ff63648ad [ELF][X86_64] Use R_GOTREL_FROM_END instead of R_GOTREL for R_X86_64_GOTOFF64
Summary:
R_X86_64_GOTOFF64: S + A - GOT
R_X86_64_GOTPC{32,64}: GOT + A - P (R_GOTONLY_PC_FROM_END)

R_X86_64_GOTOFF64 should use R_GOTREL_FROM_END so that in conjunction with
R_X86_64_GOTPC{32,64}, the `GOT` term is neutralized. This also matches
the handling of R_386_GOTOFF (S + A - GOT).

Reviewers: ruiu, espindola

Subscribers: emaste, arichardson, llvm-commits

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

llvm-svn: 334672
2018-06-13 23:29:28 +00:00
Rui Ueyama 1ebde333e8 Remove needless bitwise-AND.
Because applyMask ignores upper bits, we don't need to mask them.

llvm-svn: 334647
2018-06-13 19:58:33 +00:00
Rui Ueyama 3cc4a0825b Make a function non-member because it doesn't depend on any class.
llvm-svn: 334646
2018-06-13 19:50:10 +00:00
Rui Ueyama 803ffdbc7b Apply clang-format.
llvm-svn: 334645
2018-06-13 19:49:58 +00:00
Sid Manning 95b0c2e1e3 Add Hexagon Support
Differential Revision: https://reviews.llvm.org/D47791

llvm-svn: 334637
2018-06-13 18:45:25 +00:00
Rui Ueyama 92b931d519 Use shorter names for #lo, #hi, #ha, etc. NFC.
Since these functions are file-local, the new names shouldn't be ambiguous.

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

llvm-svn: 334564
2018-06-13 00:50:17 +00:00
Rui Ueyama 864289990a Handle R_X86_64_GOTOFF64.
R_X86_64_GOTOFF64 is a relocation type to set to a distance betwween
a symbol and the beginning of the .got section. Previously, we always
created a dynamic relocation for the relocation type even though it
can be resolved at link-time.

Creating a dynamic relocation for R_X86_64_GOTOFF64 caused link failure
for some programs that do have a relocation of the type in a .text
section, as text relocations are prohibited in most configurations.

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

llvm-svn: 334534
2018-06-12 20:27:16 +00:00
Fangrui Song 3773c196fc [ELF][PPC64] Support R_PPC64_DTPREL64 which may be emitted in .rela.debug_addr
llvm-svn: 334533
2018-06-12 20:26:49 +00:00
Fangrui Song aa473c5387 [ELF] Support R_X86_64_GOTPC{32,64}
Reviewers: ruiu, grimar, espindola

Subscribers: emaste, arichardson, llvm-commits

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

llvm-svn: 334532
2018-06-12 20:18:41 +00:00
Sean Fertile e6b2e06f28 [PPC64] Support R_PPC64_DTPREL relocations.
Patch adds support for most of the dynamic thread pointer based relocations
for local-dynamic tls. The HIGH and HIGHA versions are missing becuase they
are not supported by the llvm integrated assembler yet.

llvm-svn: 334465
2018-06-12 01:47:02 +00:00
Konstantin Zhuravlyov d70c367267 AMDGPU/LLD: Handle R_AMDGPU_REL64 relocation
Requires r334443 from llvm

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

llvm-svn: 334444
2018-06-11 21:42:53 +00:00
Zaara Syeda 4455b37666 [PPC64] Add support for local-exec TLS model
This patch adds the relocations needed support the local-exec TLS model:

R_PPC64_TPREL16
R_PPC64_TPREL16_HA
R_PPC64_TPREL16_LO
R_PPC64_TPREL16_HI
R_PPC64_TPREL16_DS
R_PPC64_TPREL16_LO_DS
R_PPC64_TPREL16_HIGHER
R_PPC64_TPREL16_HIGHERA
R_PPC64_TPREL16_HIGHEST
R_PPC64_TPREL16_HIGHESTA

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

llvm-svn: 334304
2018-06-08 17:04:09 +00:00
Zaara Syeda e4da09f920 [PPC64] Add support for initial-exec TLS model
This patch adds the relocations needed support the initial-exec TLS model:
R_PPC64_GOT_TPREL16_HA
R_PPC64_GOT_TPREL16_LO_DS
R_PPC64_GOT_TPREL16_DS
R_PPC64_GOT_TPREL16_HI
R_PPC64_TLS

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

llvm-svn: 333769
2018-06-01 15:20:56 +00:00
Sean Fertile 1a8343fce3 [PPC64] Support R_PPC64_GOT_TLSLD16 relocations.
Add support for the R_PPC64_GOT_TLSLD16 relocations used to build the address of
the tls_index struct used in local-dynamic tls.

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

llvm-svn: 333681
2018-05-31 18:44:12 +00:00
Sean Fertile fb613e552a Rename R_TLSGD/R_TLSLD to add _GOT_FROM_END. NFC.
getRelocTargetVA for R_TLSGD and R_TLSLD RelExprs calculate an offset from the
end of the got, so adjust the names to reflect this.

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

llvm-svn: 333674
2018-05-31 18:07:06 +00:00
Sean Fertile ef0f7496d1 [PPC64] Support General-Dynamic tls.
Adds handling of all the relocation types for general-dynamic thread local
storage.

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

llvm-svn: 333420
2018-05-29 14:34:38 +00:00
Rui Ueyama 1fa3c728b9 Fix retpoline PLT for x86-64 when used for >4GB address.
Previously, we wrote only the least significant 32 bits.

llvm-svn: 333313
2018-05-25 21:14:45 +00:00
Rui Ueyama 95d6ca52ac Add a comment for retpoline PLT.
llvm-svn: 333312
2018-05-25 21:02:47 +00:00
Rui Ueyama 7ae70fc14a Fix a bug that we truncated GOTPLT entries to 32 bits.
llvm-svn: 333294
2018-05-25 18:26:14 +00:00
Sean Fertile fd69969e54 [PPC64] Set the IRelative relocation type.
Set the IRelative relocation type and extend the related test to verify.
Differential Revision: https://reviews.llvm.org/D46877

llvm-svn: 333203
2018-05-24 16:32:14 +00:00
Benjamin Kramer 5455038d98 [lld] Make helpers static. NFC.
llvm-svn: 332408
2018-05-15 22:01:54 +00:00
Zaara Syeda 6b8b868db5 [ELF][PPC64] Fix getRelExpr for R_PPC64_REL64
The relocation R_PPC64_REL64 should return R_PC for getRelExpr since it
computes S + A - P.

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

llvm-svn: 332259
2018-05-14 16:39:45 +00:00
Zaara Syeda c87e16718f [ELF][PPC64] Fix getRelExpr for R_PPC64_REL32
The relocation R_PPC64_REL32 should return R_PC for getRelExpr since it
computes S + A - P.

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

llvm-svn: 332252
2018-05-14 15:26:44 +00:00
Sean Fertile 49914cc807 [PPC64] Add lazy symbol resolution stubs.
Adds support for .glink resolver stubs from the example implementation in the V2
ABI (Section 4.2.5.3. Procedure Linkage Table). The stubs are written to the
PltSection, and the sections are renamed to match the PPC64 ABI:
    .got.plt --> .plt    Type = SHT_NOBITS
    .plt     --> .glink

And adds the DT_PPC64_GLINK dynamic tag to the dynamic section when the plt is
not empty.

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

llvm-svn: 331840
2018-05-09 02:07:53 +00:00
Sean Fertile d2e887d2f6 [PPC64] Emit plt call stubs to the text section rather then the plt section.
On PowerPC calls to functions through the plt must be done through a call stub
that is responsible for:
1) Saving the toc pointer to the stack.
2) Loading the target functions address from the plt into both r12 and the
   count register.
3) Indirectly branching to the target function.

Previously we have been emitting these call stubs to the .plt section, however
the .plt section should be reserved for the lazy symbol resolution stubs. This
patch moves the call stubs to the text section by moving the implementation from
writePlt to the thunk framework.

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

llvm-svn: 331607
2018-05-06 19:13:29 +00:00
Simon Atanasyan b6211d9084 [ELF][MIPS] Reorganize isMipsPIC routine. NFC
llvm-svn: 331555
2018-05-04 20:48:53 +00:00
Zaara Syeda edc7a8c1e5 [PPC64] Remove support for ELF V1 ABI in LLD - buildbot fix
Fix buildbot error, failure to build with msvc due to error C2446
Use switch instead of ternary operator.

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

llvm-svn: 331534
2018-05-04 16:04:04 +00:00
Zaara Syeda f61b0733a8 [PPC64] Remove support for ELF V1 ABI in LLD
The current support for V1 ABI in LLD is incomplete.
This patch removes V1 ABI support and changes the default behavior to V2 ABI,
issuing an error when using the V1 ABI. It also updates the testcases to V2
and removes any V1 specific tests.

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

llvm-svn: 331529
2018-05-04 15:09:49 +00:00
Peter Smith e72d3d32bb [ELF][AArch64] Implement the AArch64 TLSLD_LDST_LO12 family of relocs
Implement the following relocations for AArch64:
R_AARCH64_TLSLE_LDST8_TPREL_LO12_NC
R_AARCH64_TLSLE_LDST16_TPREL_LO12_NC
R_AARCH64_TLSLE_LDST32_TPREL_LO12_NC
R_AARCH64_TLSLE_LDST64_TPREL_LO12_NC
R_AARCH64_TLSLE_LDST128_TPREL_LO12_NC

These are specified in ELF for the 64-bit Arm Architecture.

Fixes pr36727

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

llvm-svn: 331511
2018-05-04 08:53:34 +00:00
Simon Atanasyan bc4da23133 [ELF][MIPS] Check that a section has a valid reference to a file in the isMipsPIC routine
llvm-svn: 331470
2018-05-03 17:33:10 +00:00
Peter Smith 2e54353b86 [LLD][AArch64] Simplify relocations sharing same encoding [NFC]
The code to encode the result in relocateOne for the relocations:
R_AARCH64_LD64_GOT_LO12_NC
R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC
R_AARCH64_TLSDESC_LD64_LO12

is equivalent to that for R_AARCH64_LDST64_ABS_LO12_NC. This is described
in the ABI as "Set the LD/ST immediate field bits [11:3] of X. No overflow
check; check that X&7 =0.
    
Differential Revision: https://reviews.llvm.org/D46247

llvm-svn: 331452
2018-05-03 12:59:52 +00:00
Rafael Espindola a59aacf52b Fix trap instruction on pp64.
The test was passing on a big endian host, but just because od with x4
was compensating for it.

llvm-svn: 330386
2018-04-20 01:21:24 +00:00
George Rimar f9936e1fc9 [ELF] - Eliminate Target::isPicRel method.
As was mentioned in comments for D45158,
isPicRel's name does not make much sense,
because what this method does is checks if
we need to create the dynamic relocation or not.

Instead of renaming it to something different,
we can 'isPicRel' completely.

We can reuse the getDynRel method.
They are logically very close, getDynRel can just return
R_*_NONE in case no dynamic relocation should be produced
and that would simplify things and avoid functionality
correlation/duplication with 'isPicRel'.

The patch does this change.

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

llvm-svn: 329275
2018-04-05 12:07:20 +00:00
George Rimar 785a79133b [ELF] - X86_64: Use white list for relocations checked by isPicRel.
isPicRel is used to check if we want to create the dynamic relocations.
Not all of the dynamic relocations we create are passing through this
check, but those that are, probably better be whitelisted.

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

llvm-svn: 329203
2018-04-04 15:21:21 +00:00
George Rimar bc1d58a6b1 [ELF] - Relax checks for R_386_8/R_386_16 relocations.
This fixes PR36927.

The issue is next. Imagine we have -Ttext 0x7c and code below.

.code16
.global _start
_start:
movb $_start+0x83,%ah

So we have R_386_8 relocation and _start at 0x7C.
Addend is 0x83 == 131. We will sign extend it to 0xffffffffffffff83.

Now, 0xffffffffffffff83 + 0x7c gives us 0xFFFFFFFFFFFFFFFF.
Techically 0x83 + 0x7c == 0xFF, we do not exceed 1 byte value, but
currently LLD errors out, because we use checkUInt<8>.

Let's try to use checkInt<8> now and the following code to see if it can help (no):
main.s:
.byte foo

input.s:
.globl foo
.hidden foo
foo = 0xff

Here, foo is 0xFF. And addend is 0x0. Final value is 0x00000000000000FF.
Again, it fits one byte well, but with checkInt<8>,
we would error out it, so we can't use it.

What we want to do is to check that the result fits 1 byte well.
Patch changes the check to checkIntUInt to fix the issue.

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

llvm-svn: 329061
2018-04-03 12:19:04 +00:00
George Rimar c6735c23d2 [ELF] - X86_64: don't allow 8/16 bit dynamic relocations.
Having 8/16 bits dynamic relocations is incorrect.

Both gold and bfd (built from latest sources) disallow
that too.

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

llvm-svn: 329059
2018-04-03 11:58:23 +00:00
Rafael Espindola 3e7d6fc2c6 Define TrapInst for ppc64.
This is nice for testing since it is the first TrapInst whose bytes
are not all the same.

llvm-svn: 329014
2018-04-02 21:11:13 +00:00
Sean Fertile 227d4399bf [PPC64] Minor changes for Plt relocations.
The Plt relative relocations are R_PPC64_JMP_SLOT in the V2 abi, and we only
reserve 2 double words instead of 3 at the start of the array of PLT entries for
lazy linking.

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

llvm-svn: 329006
2018-04-02 19:47:21 +00:00
Sean Fertile af95629deb [PPC64] Write plt stubs for ElfV2 abi
Add the default version of a plt stub for the V2 Elf abi.

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

llvm-svn: 329004
2018-04-02 19:17:12 +00:00
Rui Ueyama f001ead490 Do not use template for check{Int,UInt,IntUInt,Alignment}.
Template is just unnecessary.

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

llvm-svn: 328843
2018-03-29 22:40:52 +00:00
Andrew Ng fe1d346f99 [ELF] Fix X86 & X86_64 PLT retpoline padding
The PLT retpoline support for X86 and X86_64 did not include the padding
when writing the header and entries. This issue was revealed when linker
scripts were used, as this disables the built-in behaviour of filling
the last page of executable segments with trap instructions. This
particular behaviour was hiding the missing padding.

Added retpoline tests with linker scripts.

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

llvm-svn: 328777
2018-03-29 14:03:01 +00:00
Zaara Syeda 5dd6bd9631 [ELF][PPC64] Fix getRelExpr for R_PPC64_REL16_LO and R_PPC64_REL16_HA
The relocations R_PPC64_REL16_LO and R_PPC64_REL16_HA should return R_PC
for getRelExpr since they compute #lo(S + A – P) and #ha(S + A – P).

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

llvm-svn: 328103
2018-03-21 15:04:04 +00:00
Zaara Syeda 52ed6eb8d9 [ELF] Add basic support for PPC LE
This patch adds changes to start supporting the Power 64-Bit ELF V2 ABI.
This includes:
- Changing the ElfSym::GlobalOffsetTable to be named .TOC.
- Creating a GotHeader so the first entry in the .got is .TOC.
- Setting the e_flags to be 1 for ELF V1 and 2 for ELF V2

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

llvm-svn: 327871
2018-03-19 17:40:14 +00:00
Peter Smith 3d044f57d4 [ELF] Recommit 327248 with Arm using the .got for _GLOBAL_OFFSET_TABLE_
This is the same as 327248 except Arm defining _GLOBAL_OFFSET_TABLE_ to
be the base of the .got section as some existing code is relying upon it.

For most Targets the _GLOBAL_OFFSET_TABLE_ symbol is expected to be at
the start of the .got.plt section so that _GLOBAL_OFFSET_TABLE_[0] =
reserved value that is by convention the address of the dynamic section.
Previously we had defined _GLOBAL_OFFSET_TABLE_ as either the start or end
of the .got section with the intention that the .got.plt section would
follow the .got. However this does not always hold with the current
default section ordering so _GLOBAL_OFFSET_TABLE_[0] may not be consistent
with the reserved first entry of the .got.plt.

X86, X86_64 and AArch64 will use the .got.plt. Arm, Mips and Power use .got

Fixes PR36555

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

llvm-svn: 327823
2018-03-19 06:52:51 +00:00
Peter Collingbourne 5c902845e5 Revert r327248, "For most Targets the _GLOBAL_OFFSET_TABLE_ symbol is expected to be at"
This change broke ARM code that expects to be able to add
_GLOBAL_OFFSET_TABLE_ to the result of an R_ARM_REL32.

I will provide a reproducer on llvm-commits.

llvm-svn: 327688
2018-03-16 01:01:44 +00:00
Rafael Espindola 74acdfa691 Reduce code duplication a bit.
The code for computing the offset of an entry in the plt is simple,
but it was duplicated in quite a few places.

llvm-svn: 327536
2018-03-14 17:41:34 +00:00
Peter Smith 18aa0be36e For most Targets the _GLOBAL_OFFSET_TABLE_ symbol is expected to be at
the start of the .got.plt section so that _GLOBAL_OFFSET_TABLE_[0] =
reserved value that is by convention the address of the dynamic section.
Previously we had defined _GLOBAL_OFFSET_TABLE_ as either the start or end
of the .got section with the intention that the .got.plt section would
follow the .got. However this does not always hold with the current
default section ordering so _GLOBAL_OFFSET_TABLE_[0] may not be consistent
with the reserved first entry of the .got.plt.

X86, X86_64, Arm and AArch64 will use the .got.plt. Mips and Power use .got

Fixes PR36555

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

llvm-svn: 327248
2018-03-11 20:58:18 +00:00
Fangrui Song 0c483024e4 [ELF] Convert {read,write}*be to endianness-aware read/write.
Subscribers: emaste, nemanjai, arichardson, kbarton, llvm-commits

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

llvm-svn: 327156
2018-03-09 18:03:22 +00:00
Simon Dardis f5e0b40095 [mips][lld] Address post commit review nit.
Address @ruiu's post commit review comment about a value which is intended
to be a unsigned 32 bit integer as using uint32_t rather than unsigned.

llvm-svn: 325713
2018-02-21 20:01:43 +00:00
Simon Dardis cd8758233e [mips][lld] Spectre variant two mitigation for MIPSR2
This patch provides migitation for CVE-2017-5715, Spectre variant two,
which affects the P5600 and P6600. It implements the LLD part of
-z hazardplt. Like the Clang part of this patch, I have opted for that
specific option name in case alternative migitation methods are required
in the future.

The mitigation strategy suggested by MIPS for these processors is to use
hazard barrier instructions. 'jalr.hb' and 'jr.hb' are hazard
barrier variants of the 'jalr' and 'jr' instructions respectively.

These instructions impede the execution of instruction stream until
architecturally defined hazards (changes to the instruction stream,
privileged registers which may affect execution) are cleared. These
instructions in MIPS' designs are not speculated past.

These instructions are defined by the MIPS32R2 ISA, so this mitigation
method is not compatible with processors which implement an earlier
revision of the MIPS ISA.

For LLD, this changes PLT stubs to use 'jalr.hb' and 'jr.hb'.

Reviewers: atanasyan, ruiu

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

llvm-svn: 325647
2018-02-20 23:49:17 +00:00
Simon Atanasyan bda7568dd8 [ELF][MIPS] Rename function to be consistent with other names. NFC
llvm-svn: 323650
2018-01-29 14:00:51 +00:00
Rui Ueyama 971f87a806 Fix retpoline PLT header size for i386.
Differential Revision: https://reviews.llvm.org/D42397

llvm-svn: 323288
2018-01-24 00:26:57 +00:00
Chandler Carruth c58f2166ab Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre..
Summary:
First, we need to explain the core of the vulnerability. Note that this
is a very incomplete description, please see the Project Zero blog post
for details:
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html

The basis for branch target injection is to direct speculative execution
of the processor to some "gadget" of executable code by poisoning the
prediction of indirect branches with the address of that gadget. The
gadget in turn contains an operation that provides a side channel for
reading data. Most commonly, this will look like a load of secret data
followed by a branch on the loaded value and then a load of some
predictable cache line. The attacker then uses timing of the processors
cache to determine which direction the branch took *in the speculative
execution*, and in turn what one bit of the loaded value was. Due to the
nature of these timing side channels and the branch predictor on Intel
processors, this allows an attacker to leak data only accessible to
a privileged domain (like the kernel) back into an unprivileged domain.

The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In many
cases, the compiler can simply use directed conditional branches and
a small search tree. LLVM already has support for lowering switches in
this way and the first step of this patch is to disable jump-table
lowering of switches and introduce a pass to rewrite explicit indirectbr
sequences into a switch over integers.

However, there is no fully general alternative to indirect calls. We
introduce a new construct we call a "retpoline" to implement indirect
calls in a non-speculatable way. It can be thought of loosely as
a trampoline for indirect calls which uses the RET instruction on x86.
Further, we arrange for a specific call->ret sequence which ensures the
processor predicts the return to go to a controlled, known location. The
retpoline then "smashes" the return address pushed onto the stack by the
call with the desired target of the original indirect call. The result
is a predicted return to the next instruction after a call (which can be
used to trap speculative execution within an infinite loop) and an
actual indirect branch to an arbitrary address.

On 64-bit x86 ABIs, this is especially easily done in the compiler by
using a guaranteed scratch register to pass the target into this device.
For 32-bit ABIs there isn't a guaranteed scratch register and so several
different retpoline variants are introduced to use a scratch register if
one is available in the calling convention and to otherwise use direct
stack push/pop sequences to pass the target address.

This "retpoline" mitigation is fully described in the following blog
post: https://support.google.com/faqs/answer/7625886

We also support a target feature that disables emission of the retpoline
thunk by the compiler to allow for custom thunks if users want them.
These are particularly useful in environments like kernels that
routinely do hot-patching on boot and want to hot-patch their thunk to
different code sequences. They can write this custom thunk and use
`-mretpoline-external-thunk` *in addition* to `-mretpoline`. In this
case, on x86-64 thu thunk names must be:
```
  __llvm_external_retpoline_r11
```
or on 32-bit:
```
  __llvm_external_retpoline_eax
  __llvm_external_retpoline_ecx
  __llvm_external_retpoline_edx
  __llvm_external_retpoline_push
```
And the target of the retpoline is passed in the named register, or in
the case of the `push` suffix on the top of the stack via a `pushl`
instruction.

There is one other important source of indirect branches in x86 ELF
binaries: the PLT. These patches also include support for LLD to
generate PLT entries that perform a retpoline-style indirection.

The only other indirect branches remaining that we are aware of are from
precompiled runtimes (such as crt0.o and similar). The ones we have
found are not really attackable, and so we have not focused on them
here, but eventually these runtimes should also be replicated for
retpoline-ed configurations for completeness.

For kernels or other freestanding or fully static executables, the
compiler switch `-mretpoline` is sufficient to fully mitigate this
particular attack. For dynamic executables, you must compile *all*
libraries with `-mretpoline` and additionally link the dynamic
executable and all shared libraries with LLD and pass `-z retpolineplt`
(or use similar functionality from some other linker). We strongly
recommend also using `-z now` as non-lazy binding allows the
retpoline-mitigated PLT to be substantially smaller.

When manually apply similar transformations to `-mretpoline` to the
Linux kernel we observed very small performance hits to applications
running typical workloads, and relatively minor hits (approximately 2%)
even for extremely syscall-heavy applications. This is largely due to
the small number of indirect branches that occur in performance
sensitive paths of the kernel.

When using these patches on statically linked applications, especially
C++ applications, you should expect to see a much more dramatic
performance hit. For microbenchmarks that are switch, indirect-, or
virtual-call heavy we have seen overheads ranging from 10% to 50%.

However, real-world workloads exhibit substantially lower performance
impact. Notably, techniques such as PGO and ThinLTO dramatically reduce
the impact of hot indirect calls (by speculatively promoting them to
direct calls) and allow optimized search trees to be used to lower
switches. If you need to deploy these techniques in C++ applications, we
*strongly* recommend that you ensure all hot call targets are statically
linked (avoiding PLT indirection) and use both PGO and ThinLTO. Well
tuned servers using all of these techniques saw 5% - 10% overhead from
the use of retpoline.

We will add detailed documentation covering these components in
subsequent patches, but wanted to make the core functionality available
as soon as possible. Happy for more code review, but we'd really like to
get these patches landed and backported ASAP for obvious reasons. We're
planning to backport this to both 6.0 and 5.0 release streams and get
a 5.0 release with just this cherry picked ASAP for distros and vendors.

This patch is the work of a number of people over the past month: Eric, Reid,
Rui, and myself. I'm mailing it out as a single commit due to the time
sensitive nature of landing this and the need to backport it. Huge thanks to
everyone who helped out here, and everyone at Intel who helped out in
discussions about how to craft this. Also, credit goes to Paul Turner (at
Google, but not an LLVM contributor) for much of the underlying retpoline
design.

Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer

Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits

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

llvm-svn: 323155
2018-01-22 22:05:25 +00:00
Simon Atanasyan 712cd41fa0 [ELF][MIPS] Rename function. NFC
llvm-svn: 322861
2018-01-18 15:59:10 +00:00
Simon Atanasyan ceddcdf01c [ELF][MIPS] Decompose relocation type for N32 / N64 earlier. NFC
We need to decompose relocation type for N32 / N64 ABI. Let's do it
before any other manipulations with relocation type in the `relocateOne`
routine.

llvm-svn: 322860
2018-01-18 15:59:05 +00:00
Rui Ueyama 17a3077f59 Make it clear where is a placeholder for later binary patching.
This is an aesthetic change to represent a placeholder for later
binary patching as "0, 0, 0, 0" instead of "0x00, 0x00, 0x00, 0x00".
The former is how we represent it in COFF, and I found it easier to
read than the latter.

llvm-svn: 321471
2017-12-27 06:54:18 +00:00
Rafael Espindola 1037eef8e0 Use references instead of pointers. NFC.
These values are trivially never null. While at it, also use
InputSection instead of InputSectionBase when possible.

llvm-svn: 321126
2017-12-19 23:59:35 +00:00
Shoaib Meenai 8c023a9cd9 [ELF] Fix typo in comment. NFC
llvm-svn: 321022
2017-12-18 20:33:27 +00:00
Peter Smith 3c73a41128 [ELF] Optimize Arm PLT sequences
A more efficient PLT sequence can be used when the distance between the
.plt and the end of the .plt.got is less than 128 Megabytes, which is
frequently true. We fall back to the old sequence when the offset is larger
than 128 Megabytes. This gives us an alternative to forcing the longer
entries with --long-plt as we gracefully fall back to it as needed. 

See ELF for the ARM Architecture Appendix A for details of the PLT sequence.

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

llvm-svn: 320987
2017-12-18 14:46:27 +00:00
Rafael Espindola 9c8d7f8dcc Return R_PLT_PC for R_PPC_PLTREL24.
The PPC port doesn't support PLT yet, but the architecture independent
code optimizes PLT access for non preemptible symbols, which is
exactly what returning R_PC was trying to implement.

llvm-svn: 320430
2017-12-11 22:40:18 +00:00
Tim Northover 8f1bc370e2 PPC32: Support R_PPC_PLTREL32 in static mode.
See https://reviews.llvm.org/D39226

Patch by vit9696 <vit9696@avp.su>

llvm-svn: 320286
2017-12-10 08:42:34 +00:00
Alexander Richardson 280252c6d1 [ELF][mips] Print the full file path for files with incompatible ISA
Summary:
I also changed the message to print both the ISA and the the architecture
name for incompatible files. Previously it would be quite hard to find the
actual path of the incompatible object files in projects that have many
object files with the same name in different directories.

Reviewers: atanasyan, ruiu

Reviewed By: atanasyan

Subscribers: emaste, sdardis, llvm-commits

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

llvm-svn: 320056
2017-12-07 16:08:59 +00:00
Peter Smith 31dddc97ae [ELF][AArch64] Add support for AArch64 range thunks.
The AArch64 unconditional branch and branch and link instructions have a
maximum range of 128 Mib. This is usually enough for most programs but
there are cases when it isn't enough. This change adds support for range
extension thunks to AArch64. For pc-relative thunks we follow the small
code model and use ADRP, ADD, BR. This has a limit of 4 gigabytes.

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

llvm-svn: 319307
2017-11-29 11:15:12 +00:00
Peter Smith 2809926c4d [ELF][ARM] Refine check for when undefined weak needs a Thunk
When an undefined weak reference has a PLT entry we must generate a range
extension thunk for any B or BL that can't reach the PLT entry.

This change explicitly looks for whether a PLT entry exists rather than
assuming that weak references never need PLT entries unless Config->Shared
is in operation. This covers the case where we are linking an executable
with dynamic linking, hence a PLT entry will be needed for undefined weak
references. This case comes up in real programs over 32 Mb in size as there
is a B to a weak reference __gmon__start__ in the Arm crti.o for glibc.

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

llvm-svn: 319020
2017-11-27 11:49:18 +00:00
Simon Atanasyan 167306a56c [MIPS] Write PLT0 entry in case of linking N64 ABI code
llvm-svn: 318831
2017-11-22 12:34:29 +00:00
Simon Atanasyan cfa8aa7edb [MIPS] Set STO_MIPS_MICROMIPS flag and less-significant bit for microMIPS symbols
microMIPS symbols including microMIPS PLT records created for regular
symbols needs to be marked by STO_MIPS_MICROMIPS flag in a symbol table.
Additionally microMIPS entries in a dynamic symbol table should have
configured less-significant bit. That allows to escape teaching a
dynamic linker about microMIPS symbols.

llvm-svn: 318097
2017-11-13 22:40:36 +00:00
Simon Atanasyan 5a4e21364c [MIPS] Setup less-significant bit in the .got and .got.plt entries in case of microMIPS code
The less-significant bit signals about microMIPS code for jump/branch
instructions.

llvm-svn: 317741
2017-11-08 23:34:34 +00:00
Rui Ueyama 7957b08e87 Move MIPS-specific code from Symbols.cpp to MIPS.cpp.
We have a lot of "if (MIPS)" conditions in lld because the MIPS' ABI
is different at various places than other arch's ABIs at where it
don't have to be different, but we at least want to reduce MIPS-ness
from the regular classes.

llvm-svn: 317525
2017-11-07 00:04:22 +00:00
Peter Collingbourne e9a9e0a1e7 ELF: Merge DefinedRegular and Defined.
Now that DefinedRegular is the only remaining derived class of
Defined, we can merge the two classes.

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

llvm-svn: 317448
2017-11-06 04:35:31 +00:00
Rui Ueyama f52496e1e0 Rename SymbolBody -> Symbol
Now that we have only SymbolBody as the symbol class. So, "SymbolBody"
is a bit strange name now. This is a mechanical change generated by

  perl -i -pe s/SymbolBody/Symbol/g $(git grep -l SymbolBody lld/ELF lld/COFF)

nd clang-format-diff.

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

llvm-svn: 317370
2017-11-03 21:21:47 +00:00
Peter Smith 75030b6d56 [ELF] Introduce range extension thunks for ARM
This change adds initial support for range extension thunks. All thunks must
be created within the first pass so some corner cases are not supported. A
follow up patch will add support for multiple passes.

With this change the existing tests arm-branch-error.s and
arm-thumb-branch-error.s now no longer fail with an out of range branch.
These have been renamed and tests added for the range extension thunk.

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

llvm-svn: 316752
2017-10-27 09:04:11 +00:00
Peter Smith f0c70f8d34 [ELF] Pre-create ThunkSections at Target specific intervals
When an OutputSection is larger than the branch range for a Target we
need to place thunks such that they are always in range of their caller,
and sufficiently spaced to maximise the number of callers that can use
the thunk. We use the simple heuristic of placing the
ThunkSection at intervals corresponding to a target specific branch range.
If the OutputSection is small we put the thunks at the end of the executable
sections.

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

llvm-svn: 316751
2017-10-27 08:58:28 +00:00
Rui Ueyama ed55e6c64f Remove an unnecessary inheritance.
llvm-svn: 316716
2017-10-26 23:54:00 +00:00
Bob Haarman b8a59c8aa5 [lld] unified COFF and ELF error handling on new Common/ErrorHandler
Summary:
The COFF linker and the ELF linker have long had similar but separate
Error.h and Error.cpp files to implement error handling. This change
introduces new error handling code in Common/ErrorHandler.h, changes the
COFF and ELF linkers to use it, and removes the old, separate
implementations.

Reviewers: ruiu

Reviewed By: ruiu

Subscribers: smeenai, jyknight, emaste, sdardis, nemanjai, nhaehnle, mgorny, javed.absar, kbarton, fedor.sergeev, llvm-commits

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

llvm-svn: 316624
2017-10-25 22:28:38 +00:00
Rui Ueyama f8f4620dc6 Move comment to the place where it makes more sense.
llvm-svn: 316491
2017-10-24 20:11:07 +00:00
Rui Ueyama 51f604ce66 Simplify.
llvm-svn: 316486
2017-10-24 19:40:03 +00:00
Konstantin Zhuravlyov b71d1b8a54 LLD/ELF/AMDGPU: Process AMDGPU-specific e_flags
Differential Revision: https://reviews.llvm.org/D39140

llvm-svn: 316483
2017-10-24 19:05:32 +00:00
Konstantin Zhuravlyov e7f1734f1a LLD/ELF: Allow targets to set e_flags
Differential Revision: https://reviews.llvm.org/D39139

llvm-svn: 316460
2017-10-24 17:01:40 +00:00
Rui Ueyama 8faafa4fb1 Add R_PPC_ADDR16_HI relocation support
The support of R_PPC_ADDR16_HI improves ld compatibility and makes
things on par with RuntimeDyldELF that already implements this
relocation.

Patch by vit9696.

llvm-svn: 316306
2017-10-22 23:33:49 +00:00
Tony Tye 394e1dde6e Add base relative relocation record that can be used for the following case (OpenCL example):
static __global int Var = 0; 
__global int* Ptr[] = {&Var};
...

In this case Var is a non premptable symbol and so its address can be used as the value of Ptr, with a base relative relocation that will add the delta between the ELF address and the actual load address. Such relocations do not require a symbol.

This also fixes LLD which was incorrectly generating a PCREL64 for this case.

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

llvm-svn: 315936
2017-10-16 20:46:53 +00:00
Petr Hosek ac40140e24 [ELF] Recognize additional relocation types
These are generated by the linker itself and it shouldn't treat
them as unrecognized. This was introduced in r315552 and is triggering
an error when building UBSan shared library for i386.

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

llvm-svn: 315737
2017-10-13 19:30:00 +00:00
Rui Ueyama be85529d2b Remove one parameter from Target::getRelExpr.
A section was passed to getRelExpr just to create an error message.
But if there's an invalid relocation, we would eventually report it
in relocateOne. So we don't have to pass a section to getRelExpr.

llvm-svn: 315552
2017-10-12 03:14:06 +00:00
Rui Ueyama 63e49d489b Rewrite comment.
llvm-svn: 315548
2017-10-12 02:09:11 +00:00
Rui Ueyama 67533a2cb3 Define RelType to represent relocation types.
We were using uint32_t as the type of relocation kind. It has a
readability issue because what Type really means in `uint32_t Type`
is not obvious. It could be a section type, a symbol type or a
relocation type.

Since we do not do any arithemetic operations on relocation types
(e.g. adding one to R_X86_64_PC32 doesn't make sense), it would be
more natural if they are represented as enums. Unfortunately, that
is not doable because relocation type definitions are spread into
multiple header files.

So I decided to use typedef. This still should be better than the
plain uint32_t because the intended type is now obvious.

llvm-svn: 315525
2017-10-11 22:49:24 +00:00
Alexander Richardson f52a3b94e1 [ELF][MIPS] Check for overflow when writing R_MIPS_CALL16 and R_MIPS_TLS_GOTTPREL
Summary:
These are 16 bit relocations and not part of a HI/LO pair so we need to
check that they don't overflow.

Reviewers: atanasyan

Reviewed By: atanasyan

Subscribers: ruiu, llvm-commits, emaste, sdardis

Tags: #lld

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

llvm-svn: 315073
2017-10-06 16:15:59 +00:00
Simon Atanasyan f8db45361e [MIPS] Generate thunks for microMIPS code
If symbol has the STO_MIPS_MICROMIPS flag and requires a thunk to perform
call PIC from non-PIC functions, we need to generate a thunk with microMIPS
code.

llvm-svn: 314797
2017-10-03 13:30:02 +00:00
Simon Atanasyan 649e4d328f [MIPS] Fix PLT entries generation in case of linking regular and microMIPS code
Currently LLD calls the `isMicroMips` routine to determine type of PLT entries
needs to be generated: regular or microMIPS. This routine checks ELF
header flags in the `FirstObj` to retrieve type of linked object files.
So if the first file does not contain microMIPS code, LLD will generate
PLT entries with regular (non-microMIPS) code only.

Ideally, if a PLT entry is referenced by microMIPS code only this entry
should contain microMIPS code, if a PLT entry is referenced by regular
code this entry should contain regular code. In a "mixed" case the PLT
entry can be either microMIPS or regular, but each "cross-mode-call" has
additional cost.

It's rather difficult to implement this ideal solution. But we can
assume that if there is an input object file with microMIPS code, the
most part of the code is microMIPS too. So we need to deduce type of PLT
entries based on finally calculated ELF header flags and do not check
only the first input object file.

This change implements this.
  - The `getMipsEFlags` renamed to the `calcMipsEFlags`. The function
    called from the `LinkerDriver::link`. Result is stored in
    the Configuration::MipsEFlags field.
  - The `isMicroMips` and `isMipsR6` routines access the `MipsEFlags`
    field to get and check calculated ELF flags.
  - New types of PLT records created when necessary.

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

llvm-svn: 314675
2017-10-02 14:56:41 +00:00
Simon Atanasyan af273f203c [MIPS] Explicitly list supported relocations for MIPS target. NFC
This is change is inspired by the D28611 patch. New supported
relocations have been added to the switch statement.

llvm-svn: 313882
2017-09-21 14:40:32 +00:00
Davide Italiano bb0690e486 [AArch64] Properly check alignment for AARCH64_LD_PREL_LO19.
Follow-up suggested by Peter Smith.

llvm-svn: 313850
2017-09-21 00:26:28 +00:00
Davide Italiano f681a8fa3a [AArch64] Implement R_AARCH64_ LD_PREL_LO19.
Fixes PR34660.

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

llvm-svn: 313841
2017-09-20 23:49:50 +00:00
George Rimar 696a7f9ac6 [ELF] - Introduce std::vector<InputFile *> global arrays.
This patch removes lot of static Instances arrays from different input file 
classes and introduces global arrays for access instead. Similar to arrays we
have for InputSections/OutputSectionCommands.

It allows to iterate over input files in a non-templated code.

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

llvm-svn: 313619
2017-09-19 09:20:54 +00:00
Rafael Espindola 3d9f1c032a Add a helper for checking for weak undef. NFC.
llvm-svn: 313188
2017-09-13 20:43:04 +00:00
Simon Atanasyan 4f70b30d6f [MIPS] Initial support of microMIPS code linking
The patch implements initial support of microMIPS code linking:
  - Handle microMIPS specific relocations.
  - Emit both R1-R5 and R6 microMIPS PLT records.

For now linking mixed set of regular and microMIPS object files is not
supported. Also the patch does not handle (setup and clear) the
least-significant bit of an address which is utilized as the ISA mode
bit and allows to make jump between regular and microMIPS code without
any thunks.

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

llvm-svn: 313028
2017-09-12 13:08:24 +00:00
Peter Smith 20489ec563 [ELF] Always write non-immediate bits for AArch64 branch instruction.
To support errata patching on AArch64 we need to be able to overwrite
an arbitrary instruction with a branch. For AArch64 it is sufficient to
always write all the bits of the branch instruction and not just the
immediate field. This is safe as the non-immediate bits of the branch
instruction are always the same.

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

llvm-svn: 312727
2017-09-07 16:29:52 +00:00
Peter Smith 1d5a070386 [ELF][AArch64] Add alignment checks for the LDST<N>_ABS_LO12_NC relocations
The R_AARCH64_LDST<N>_ABS LO12_NC relocations where N is 8, 16, 32, 64 or
128 have a scaled immediate. For example R_AARCH64_LDST32_ABS_LO12_NC
shifts the calculated value right by 4. If the target symbol + relocation
addend is not aligned properly then bits of the answer will be lost.

This change adds an alignment check to the relocations to make sure the
target of the relocation is aligned properly. This matches the behavior of
GNU ld. The motivation is to catch ODR violations such as a declaration of
extern int foo, but a definition of bool foo as the compiler may use
R_AARCH64_LDST32_ABS_LO12_NC for the former, but not align the destination.

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

llvm-svn: 312637
2017-09-06 14:23:06 +00:00
Simon Atanasyan 7644191fb1 [MIPS] Convert template parameters to function arguments. NFC
Pass BSIZE and SHIFT as a function arguments to the `writeRelocation`
routine. It does not make a sense to have so many `writeRelocation's`
instances.

llvm-svn: 312495
2017-09-04 16:16:46 +00:00
Simon Atanasyan 351cf49579 [MIPS] Add curly brackets to improve code readability. NFC.
llvm-svn: 312494
2017-09-04 16:16:41 +00:00
George Rimar b2051f176c [ELF] - Fix comment. NFC.
llvm-svn: 312231
2017-08-31 10:14:10 +00:00
Simon Atanasyan 3876077ac7 [MIPS] Remove unused function's argument. NFC
llvm-svn: 311889
2017-08-28 14:40:53 +00:00
Simon Atanasyan 1998f859dc [MIPS] Merge multiple functions for writing relocation result into the single one. NFC
llvm-svn: 311712
2017-08-24 21:57:03 +00:00
Simon Atanasyan c5455e237f [MIPS] Keep all code read addends in the `getImplicitAddend` function
Currently LLD reads the R_MIPS_HI16's addends in the `computeMipsAddend`
function, the R_MIPS_LO16's addends in both `computeMipsAddend` and
`getImplicitAddend` functions. This patch moves reading all addends to
the `getImplicitAddend` function. As a side effect it fixes a "paired"
HI16/LO16 addend calculation if "LO16" part of a pair is not found.

llvm-svn: 311711
2017-08-24 21:56:58 +00:00
Simon Atanasyan 204cae99bb [MIPS] Remove redundant function getPcRelocAddend. NFC
llvm-svn: 311710
2017-08-24 21:56:52 +00:00
Rafael Espindola 3bab91332f Fix which file is in an error message.
When reporting an invalid relocation we were blaming the destination
file instead of the file with the relocation.

llvm-svn: 310084
2017-08-04 18:33:16 +00:00
Rui Ueyama 709fb2bb10 Rename ObjectFile -> ObjFile.
Rename it because it was too easy to conflict with llvm::object::ObjectFile
which broke buildbots several times.

llvm-svn: 309199
2017-07-26 22:13:32 +00:00
Rafael Espindola 244ef98161 Detemplate SymbolTable.
NFC, just makes it easier to access from non templated code.

llvm-svn: 309152
2017-07-26 18:42:48 +00:00
George Rimar 67c60727ce [ELF] - Apply clang-format. NFC.
llvm-svn: 308297
2017-07-18 11:55:35 +00:00
Peter Smith a49442f323 [ELF] Introduce target specific inBranchRange() function
In preparation for range extension thunks introduce a function that will
check whether a branch identified by a relocation type at a source address
can reach a destination.

For targets where range extension thunks are not supported the function will
return true as it is not expected that branches are out of range. An
implementation has been provided for ARM.

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

llvm-svn: 308188
2017-07-17 16:54:29 +00:00
Rafael Espindola b04290569c Delete comparison with GlobalOffsetTable.
Now that _GLOBAL_OFFSET_TABLE_ is defined, we can just use R_PC for it
if needed.

llvm-svn: 306614
2017-06-28 23:19:32 +00:00
Rui Ueyama 0cc1483562 Add basic 64-bit SPARC support
Add support for the most common SPARC relocations.
Make DT_PLTGOT point to the PLT on SPARC.
Mark the PLT as executable on SPARC.

This adds a basic test that creates a SPARV9 executable
that invokes the exit system call on OpenBSD.

Patch by Mark Kettenis.

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

llvm-svn: 306565
2017-06-28 17:05:39 +00:00
Rui Ueyama 921d43fbb2 Add trap instructions for ARM and MIPS.
This patch fills holes in executable sections with 0xd4 (ARM) or
0xef (MIPS). These trap instructions were suggested by Theo de Raadt.

llvm-svn: 306322
2017-06-26 19:45:53 +00:00
Peter Smith 113a59e7db [ELF] Define _GLOBAL_OFFSET_TABLE_ symbol relative to .got
On many architectures gcc and clang will recognize _GLOBAL_OFFSET_TABLE_ - .
and produce a relocation that can be processed without needing to know the
value of _GLOBAL_OFFSET_TABLE_. This is not always the case; for example ARM
gcc produces R_ARM_BASE_PREL but clang produces the more general
R_ARM_REL32 to _GLOBAL_OFFSET_TABLE_. To evaluate this relocation
correctly _GLOBAL_OFFSET_TABLE_ must be defined to be the either the base of
the GOT or end of the GOT dependent on architecture..

If/when llvm-mc is changed to recognize _GLOBAL_OFFSET_TABLE_ - . this
change will not be necessary for new objects. However there may still be
old objects and versions of clang.

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

llvm-svn: 306282
2017-06-26 10:22:17 +00:00
Konstantin Zhuravlyov f3e3629f3d LLD: Move ELF/Mips.cpp to ELF/Arch/MipsArchTree.cpp
Differential Revision: https://reviews.llvm.org/D34358

llvm-svn: 305742
2017-06-19 21:03:57 +00:00
Rui Ueyama e145bc22fd Do not use make<> to allocate TargetInfo. NFC.
llvm-svn: 305577
2017-06-16 20:15:03 +00:00
Rui Ueyama c9fefaac67 Add comments for AVR support.
AVR support is somewhat exotic as generated ELF executables are not
directly consumed but objcopy'ed to write it to on-chip flush memory.
This comment describes it for those why a full-fledged ELF linker is
used to link programs for the 8-bit microcontroller.

llvm-svn: 305567
2017-06-16 17:53:26 +00:00
Rui Ueyama 21c0a9ceeb Split Target.cpp into small files.
Target.cpp contains code for all the targets that LLD supports. It was
simple and easy, but as the number of supported targets increased,
it got messy.

This patch splits the file into per-target files under ELF/arch directory.

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

llvm-svn: 305565
2017-06-16 17:32:43 +00:00