summaryrefslogtreecommitdiffstats
path: root/lld/ELF/Arch
Commit message (Collapse)AuthorAgeFilesLines
* [LLD][ELF][ARM] Do not insert interworking thunks for non STT_FUNC symbolsPeter Smith2020-01-291-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | ELF for the ARM architecture requires linkers to provide interworking for symbols that are of type STT_FUNC. Interworking for other symbols must be encoded directly in the object file. LLD was always providing interworking, regardless of the symbol type, this breaks some programs that have branches from Thumb state targeting STT_NOTYPE symbols that have bit 0 clear, but they are in fact internal labels in a Thumb function. LLD treats these symbols as ARM and inserts a transition to Arm. This fixes the problem for in range branches, R_ARM_JUMP24, R_ARM_THM_JUMP24 and R_ARM_THM_JUMP19. This is expected to be the vast majority of problem cases as branching to an internal label close to the function. There is at least one follow up patch required. - R_ARM_CALL and R_ARM_THM_CALL may do interworking via BL/BLX substitution. In theory range-extension thunks can be altered to not change state when the symbol type is not STT_FUNC. I will need to check with ld.bfd to see if this is the case in practice. Fixes (part of) https://github.com/ClangBuiltLinux/linux/issues/773 Differential Revision: https://reviews.llvm.org/D73474 (cherry picked from commit 4f38ab250ff4680375c4c01db0a88c157093c665)
* [ELF][PPC32] Support range extension thunks with addendsFangrui Song2020-01-251-5/+5
| | | | | | | | | | | * Generalize the code added in D70637 and D70937. We should eventually remove the EM_MIPS special case. * Handle R_PPC_LOCAL24PC the same way as R_PPC_REL24. Reviewed By: Bdragon28 Differential Revision: https://reviews.llvm.org/D73424 (cherry picked from commit 70389be7a029bec3c45991a60b627445ef996120)
* [ELF][PPC32] Support canonical PLTFangrui Song2020-01-251-8/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -fno-pie produces a pair of non-GOT-non-PLT relocations R_PPC_ADDR16_{HA,LO} (R_ABS) referencing external functions. ``` lis 3, func@ha la 3, func@l(3) ``` In a -no-pie/-pie link, if func is not defined in the executable, a canonical PLT entry (st_value>0, st_shndx=0) will be needed. References to func in shared objects will be resolved to this address. -fno-pie -pie should fail with "can't create dynamic relocation ... against ...", so we just need to think about -no-pie. On x86, the PLT entry passes the JMP_SLOT offset to the rtld PLT resolver. On x86-64: the PLT entry passes the JUMP_SLOT index to the rtld PLT resolver. On ARM/AArch64: the PLT entry passes &.got.plt[n]. The PLT header passes &.got.plt[fixed-index]. The rtld PLT resolver can compute the JUMP_SLOT index from the two addresses. For these targets, the canonical PLT entry can just reuse the regular PLT entry (in PltSection). On PPC32: PltSection (.glink) consists of `b PLTresolve` instructions and `PLTresolve`. The rtld PLT resolver depends on r11 having been set up to the .plt (GotPltSection) entry. On PPC64 ELFv2: PltSection (.glink) consists of `__glink_PLTresolve` and `bl __glink_PLTresolve`. The rtld PLT resolver depends on r12 having been set up to the .plt (GotPltSection) entry. We cannot reuse a `b PLTresolve`/`bl __glink_PLTresolve` in PltSection as a canonical PLT entry. PPC64 ELFv2 avoids the problem by using TOC for any external reference, even in non-pic code, so the canonical PLT entry scenario should not happen in the first place. For PPC32, we have to create a PLT call stub as the canonical PLT entry. The code sequence sets up r11. Reviewed By: Bdragon28 Differential Revision: https://reviews.llvm.org/D73399 (cherry picked from commit 837e8a9c0cd097034e023dfba146d17ce132998c)
* [lld][RISCV] Print error when encountering R_RISCV_ALIGNJames Clarke2020-01-241-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Unlike R_RISCV_RELAX, which is a linker hint, R_RISCV_ALIGN requires the support of the linker even when ignoring all R_RISCV_RELAX relocations. This is because the compiler emits as many NOPs as may be required for the requested alignment, more than may be required pre-relaxation, to allow for the target becoming more unaligned after relaxing earlier sequences. This means that the target is often not initially aligned in the object files, and so the R_RISCV_ALIGN relocations cannot just be ignored. Since we do not support linker relaxation, we must turn these into errors. Reviewers: ruiu, MaskRay, espindola Reviewed By: MaskRay Subscribers: grimar, Jim, emaste, arichardson, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71820 (cherry picked from commit d1da63664f4e42191daf2e6a9fa682ca9f75ef5e)
* [ELF][PowerPC] Support R_PPC_COPY and R_PPC64_COPYFangrui Song2020-01-242-0/+2
| | | | | | | | Reviewed By: Bdragon28, jhenderson, grimar, sfertile Differential Revision: https://reviews.llvm.org/D73255 (cherry picked from commit f1dab29908d25a4044abff6ffc120c48b20f034d)
* [ELF] Delete the RelExpr member R_HINT. NFCFangrui Song2020-01-141-1/+1
| | | | | | | R_HINT is ignored like R_NONE. There are no strong reasons to keep R_HINT. The largest RelExpr member R_RISCV_PC_INDIRECT is 60 now. Differential Revision: https://reviews.llvm.org/D71822
* [ELF] Add -z force-ibt and -z shstk for Intel Control-flow Enforcement ↵Fangrui Song2020-01-132-1/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | | Technology This patch is a joint work by Rui Ueyama and me based on D58102 by Xiang Zhang. It adds Intel CET (Control-flow Enforcement Technology) support to lld. The implementation follows the draft version of psABI which you can download from https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI. CET introduces a new restriction on indirect jump instructions so that you can limit the places to which you can jump to using indirect jumps. In order to use the feature, you need to compile source files with -fcf-protection=full. * IBT is enabled if all input files are compiled with the flag. To force enabling ibt, pass -z force-ibt. * SHSTK is enabled if all input files are compiled with the flag, or if -z shstk is specified. IBT-enabled executables/shared objects have two PLT sections, ".plt" and ".plt.sec". For the details as to why we have two sections, please read the comments. Reviewed By: xiangzhangllvm Differential Revision: https://reviews.llvm.org/D59780
* [ELF][Hexagon] Add support for IE relocationsSid Manning2020-01-091-0/+22
| | | | Differential Revision: https://reviews.llvm.org/D71143
* [LLD][ELF][AArch64] Do not use thunk for undefined weak symbol.Peter Smith2020-01-071-0/+4
| | | | | | | | | | | | | | | In AArch64 a branch to an undefined weak symbol that does not have a PLT entry should resolve to the next instruction. The thunk generation code can prevent this from happening as a range extension thunk can be generated if the branch is sufficiently far away from 0, the value of an undefined weak symbol. The fix is taken from the Arm implementation of needsThunk(), we prevent a thunk from being generated to an undefined weak symbol. fixes pr44451 Differential Revision: https://reviews.llvm.org/D72267
* [lld] Fix trivial typos in commentsKazuaki Ishizaki2020-01-061-1/+1
| | | | | | Reviewed By: ruiu, MaskRay Differential Revision: https://reviews.llvm.org/D72196
* Add TPREL relocation support to HexagonSid Manning2020-01-021-0/+15
| | | | Differential Revision: https://reviews.llvm.org/D71069
* [ELF][RISCV] Improve error message for unknown relocationsFangrui Song2019-12-311-16/+15
| | | | Like rLLD354040.
* [ELF][PPC32] Implement IPLT code sequence for non-preemptible IFUNCFangrui Song2019-12-291-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Similar to D71509 (EM_PPC64), on EM_PPC, the IPLT code sequence should be similar to a PLT call stub. Unlike EM_PPC64, EM_PPC -msecure-plt has small/large PIC model differences. * -fpic/-fpie: R_PPC_PLTREL24 r_addend=0. The call stub loads an address relative to `_GLOBAL_OFFSET_TABLE_`. * -fPIC/-fPIE: R_PPC_PLTREL24 r_addend=0x8000. (A partial linked object file may have an addend larger than 0x8000.) The call stub loads an address relative to .got2+0x8000. Just assume large PIC model for now. This patch makes: // clang -fuse-ld=lld -msecure-plt -fno-pie -no-pie a.c // clang -fuse-ld=lld -msecure-plt -fPIE -pie a.c #include <stdio.h> static void impl(void) { puts("meow"); } void thefunc(void) __attribute__((ifunc("resolver"))); void *resolver(void) { return &impl; } int main(void) { thefunc(); void (*theptr)(void) = &thefunc; theptr(); } work on Linux glibc. -fpie will crash because the compiler and the linker do not agree on the value which r30 stores (_GLOBAL_OFFSET_TABLE_ vs .got2+0x8000). Differential Revision: https://reviews.llvm.org/D71621
* [ELF][PPC64] Implement IPLT code sequence for non-preemptible IFUNCFangrui Song2019-12-291-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Non-preemptible IFUNC are placed in in.iplt (.glink on EM_PPC64). If there is a non-GOT non-PLT relocation, for pointer equality, we change the type of the symbol from STT_IFUNC and STT_FUNC and bind it to the .glink entry. On EM_386, EM_X86_64, EM_ARM, and EM_AARCH64, the PLT code sequence loads the address from its associated .got.plt slot. An IPLT also has an associated .got.plt slot and can use the same code sequence. On EM_PPC64, the PLT code sequence is actually a bl instruction in .glink . It jumps to `__glink_PLTresolve` (the PLT header). and `__glink_PLTresolve` computes the .plt slot (relocated by R_PPC64_JUMP_SLOT). An IPLT does not have an associated R_PPC64_JUMP_SLOT, so we cannot use `bl` in .iplt . Instead, create a call stub which has a similar code sequence as PPC64PltCallStub. We don't save the TOC pointer, so such scenarios will not work: a function pointer to a non-preemptible ifunc, which resolves to a function defined in another DSO. This is the restriction described by https://sourceware.org/glibc/wiki/GNU_IFUNC (though on many architectures it works in practice): Requirement (a): Resolver must be defined in the same translation unit as the implementations. If an ifunc is taken address but not called, technically we don't need an entry for it, but we currently do that. This patch makes // clang -fuse-ld=lld -fno-pie -no-pie a.c // clang -fuse-ld=lld -fPIE -pie a.c #include <stdio.h> static void impl(void) { puts("meow"); } void thefunc(void) __attribute__((ifunc("resolver"))); void *resolver(void) { return &impl; } int main(void) { thefunc(); void (*theptr)(void) = &thefunc; theptr(); } work on Linux glibc and FreeBSD. Calling a function pointer pointing to a Non-preemptible IFUNC never worked before. Differential Revision: https://reviews.llvm.org/D71509
* [lld][RISCV] Use an e_flags of 0 if there are only binary input files.John Baldwin2019-12-211-1/+4
| | | | | | | | | | | | | | | | | | Summary: If none of the input files are ELF object files (for example, when generating an object file from a single binary input file via "-b binary"), use a fallback value for the ELF header flags instead of crashing with an assertion failure. Reviewers: MaskRay, ruiu, espindola Reviewed By: MaskRay, ruiu Subscribers: kevans, grimar, emaste, arichardson, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits, jrtc27 Tags: #llvm Differential Revision: https://reviews.llvm.org/D71101
* [ELF] writePlt, writeIplt: replace parameters gotPltEntryAddr and index with ↵Fangrui Song2019-12-1810-75/+80
| | | | | | | | | | `const Symbol &`. NFC PPC::writeIplt (IPLT code sequence, D71621) needs to access `Symbol`. Reviewed By: grimar, ruiu Differential Revision: https://reviews.llvm.org/D71631
* [ELF] Add IpltSectionFangrui Song2019-12-177-13/+26
| | | | | | | | | | | | | | | | | | | PltSection is used by both PLT and IPLT. The PLT section may have a header while the IPLT section does not. Split off IpltSection from PltSection to be clearer. Unlike other targets, PPC64 cannot use the same code sequence for PLT and IPLT. This helps make a future PPC64 patch (D71509) more isolated. On EM_386 and EM_X86_64, when PLT is empty while IPLT is not, currently we are inconsistent whether the PLT header is conceptually attached to in.plt or in.iplt . Consistently attach the header to in.plt can make the -z retpolineplt logic simpler. It also makes `jmp` point to an aesthetically better place for non-retpolineplt cases. Reviewed By: grimar, ruiu Differential Revision: https://reviews.llvm.org/D71519
* [ELF] Delete relOff from TargetInfo::writePLTFangrui Song2019-12-1610-46/+34
| | | | | | | | | | | | | | This change only affects EM_386. relOff can be computed from `index` easily, so it is unnecessarily passed as a parameter. Both in.plt and in.iplt entries are written by writePLT. For in.iplt, the instruction `push reloc_offset` will change because `index` is now different. Fortunately, this does not matter because `push; jmp` is only used by PLT. IPLT does not need the code sequence. Reviewed By: grimar, ruiu Differential Revision: https://reviews.llvm.org/D71518
* [ELF][PPC64] Support long branch thunks with addendsFangrui Song2019-12-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes PPC64 part of PR40438 // clang -target ppc64le -c a.cc // .text.unlikely may be placed in a separate output section (via -z keep-text-section-prefix) // The distance between bar in .text.unlikely and foo in .text may be larger than 32MiB. static void foo() {} __attribute__((section(".text.unlikely"))) static int bar() { foo(); return 0; } __attribute__((used)) static int dummy = bar(); This patch makes such thunks with addends work for PPC64. AArch64: .text -> `__AArch64ADRPThunk_ (adrp x16, ...; add x16, x16, ...; br x16)` -> target PPC64: .text -> `__long_branch_ (addis 12, 2, ...; ld 12, ...(12); mtctr 12; bctr)` -> target AArch64 can leverage ADRP to jump to the target directly, but PPC64 needs to load an address from .branch_lt . Before Power ISA v3.0, the PC-relative ADDPCIS was not available. .branch_lt was invented to work around the limitation. Symbol::ppc64BranchltIndex is replaced by PPC64LongBranchTargetSection::entry_index which take addends into consideration. The tests are rewritten: ppc64-long-branch.s tests -no-pie and ppc64-long-branch-pi.s tests -pie and -shared. Reviewed By: sfertile Differential Revision: https://reviews.llvm.org/D70937
* [ELF][AArch64] Support R_AARCH64_{CALL26,JUMP26} range extension thunks with ↵Fangrui Song2019-12-025-11/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | addends Fixes AArch64 part of PR40438 The current range extension thunk framework does not handle a relocation relative to a STT_SECTION symbol with a non-zero addend, which may be used by jumps/calls to local functions on some RELA targets (AArch64, powerpc ELFv1, powerpc64 ELFv2, etc). See PR40438 and the following code for examples: // clang -target $target a.cc // .text.cold may be placed in a separate output section. // The distance between bar in .text.cold and foo in .text may be larger than 128MiB. static void foo() {} __attribute__((section(".text.cold"))) static int bar() { foo(); return 0; } __attribute__((used)) static int dummy = bar(); This patch makes such thunks with addends work for AArch64. The target independent part can be reused by PPC in the future. On REL targets (ARM, MIPS), jumps/calls are not represented as STT_SECTION + non-zero addend (see MCELFObjectTargetWriter::needsRelocateWithSymbol), so they don't need this feature, but we need to make sure this patch does not affect them. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D70637
* Ignore R_MIPS_JALR relocations against non-function symbolsAlex Richardson2019-11-201-0/+11
| | | | | | | | | | | | | | | | | | | | Summary: Current versions of clang would erroneously emit this relocation not only against functions (loaded from the GOT) but also against data symbols (e.g. a table of function pointers). LLD was then changing this into a branch-and-link instruction, causing the program to jump to the data symbol at run time. I discovered this problem when attempting to boot MIPS64 FreeBSD after updating the to the latest upstream master. Reviewers: atanasyan, jrtc27, espindola Reviewed By: atanasyan Subscribers: emaste, sdardis, krytarowski, MaskRay, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70406
* Fix a few typos in lld/ELF to cycle botsNico Weber2019-10-281-3/+3
|
* [lld] Check for branch range overflows.Sid Manning2019-10-151-0/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D68875 llvm-svn: 374891
* [lld][Hexagon] Support PLT relocation R_HEX_B15_PCREL_X/R_HEX_B9_PCREL_XSid Manning2019-10-081-2/+2
| | | | | | | | These are sometimes generated by tail call optimizations. Differential Revision: https://reviews.llvm.org/D66542 llvm-svn: 374052
* [ELF][MIPS] De-template writeValue. NFCFangrui Song2019-10-071-23/+20
| | | | | | Depends on D68561. llvm-svn: 373886
* [ELF] Wrap things in `namespace lld { namespace elf {`, NFCFangrui Song2019-10-0714-68/+121
| | | | | | | | | | | This makes it clear `ELF/**/*.cpp` files define things in the `lld::elf` namespace and simplifies `elf::foo` to `foo`. Reviewed By: atanasyan, grimar, ruiu Differential Revision: https://reviews.llvm.org/D68323 llvm-svn: 373885
* [ELF][MIPS] Use lld::elf::{read,write}* instead of ↵Fangrui Song2019-10-071-70/+68
| | | | | | | | | | | | | | llvm::support::endian::{read,write}* This allows us to delete `using namespace llvm::support::endian` and simplify D68323. This change adds runtime config->endianness check but the overhead should be negligible. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D68561 llvm-svn: 373884
* [mips] Relax jalr/jr instructions using R_MIPS_JALR relocationSimon Atanasyan2019-09-261-1/+21
| | | | | | | | | | | The R_MIPS_JALR relocation denotes jalr/jr instructions in position independent code. Both these instructions take a target's address from the $25 register. If offset to the target symbol fits into the 18-bits, it's more efficient to replace jalr/jr by bal/b instructions. Differential Revision: https://reviews.llvm.org/D68057 llvm-svn: 372951
* [LLD][ELF][MIPS] - Inline the short helper function. NFC.George Rimar2019-09-241-10/+8
| | | | | | It was requested in a post-commit comment for r372570. llvm-svn: 372747
* [LLD][ELF] - Simplify getFlagsFromEmulation(). NFCI.George Rimar2019-09-231-12/+2
| | | | | | A straightforward simplification. llvm-svn: 372570
* [mips] Deduce MIPS specific ELF header flags from `emulation`Simon Atanasyan2019-09-221-1/+19
| | | | | | | | | In case of linking binary blobs which do not have any ELF headers, we can deduce MIPS ABI ELF header flags from an `emulation` option. Patch by Kyle Evans. llvm-svn: 372513
* [ELF][Hexagon] Improve error message for unknown relocationsFangrui Song2019-08-191-3/+18
| | | | | | | | | | | | | | | | | | | | Like rLLD354040 Previously, for unknown relocation types, in -no-pie/-pie mode, we got something like: foo.o: unrecognized relocation ... In -shared mode: error: can't create dynamic relocation ... against symbol: yyy in readonly segment Delete the default case from Hexagon::getRelExpr and add the error there. We will get consistent error message like `error: unknown relocation (1024) against symbol foo` Reviewed By: sidneym Differential Revision: https://reviews.llvm.org/D66275 llvm-svn: 369260
* [lld][Hexagon] Add GOTREL relocations.Sid Manning2019-08-191-0/+11
| | | | | | | | Add GOTREL relocation support. (S + A - GOT) Differential Revision: https://reviews.llvm.org/D66260 llvm-svn: 369258
* [ELF][PPC] Fix getRelExpr for R_PPC64_REL16_HIFangrui Song2019-08-171-0/+1
| | | | | | | | | | | | Fixes https://github.com/ClangBuiltLinux/linux/issues/640 R_PPC64_REL16_HI was incorrectly computed as an R_ABS relocation. rLLD368964 made it a linker failure. Change it to use R_PC to fix the failures. Add ppc64-reloc-rel.s for these R_PPC64_REL* tests. llvm-svn: 369184
* [ELF][Hexagon] Replace R_HEXAGON_GOT with R_GOTPLTFangrui Song2019-08-161-1/+1
| | | | | | | | | | | R_GOTPLT is relative to .got.plt since D59594. Since R_HEXAGON_GOT relocations always have 0 r_addend, they can use R_GOTPLT instead. Reviewed By: sidneym Differential Revision: https://reviews.llvm.org/D66274 llvm-svn: 369128
* [lld][Hexagon]Support HEX_32 when building shared objectsSid Manning2019-08-161-0/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D66105 llvm-svn: 369121
* [ELF][AArch64] Improve error message for unknown relocationsFangrui Song2019-08-151-2/+24
| | | | | | | | | | | | | | | | | | | | Like rLLD354040. Previously, for unrecognized relocation types, in -no-pie/-pie mode, we got something like: foo.o: unrecognized relocation ... In -shared mode: error: can't create dynamic relocation ... against symbol: yyy in readonly segment Delete the default case from AArch64::getRelExpr and add the error there. Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D66277 llvm-svn: 368983
* [ELF][PPC] Improve error message for unknown relocationsFangrui Song2019-08-152-4/+30
| | | | | | | | | | | | | | Like rLLD354040. Previously, for unrecognized relocation types, in -no-pie mode: foo.o: unrecognized reloc 256 In -pie/-shared mode: error: can't create dynamic relocation R_PPC_xxx against symbol: yyy in readonly segment llvm-svn: 368964
* [ELF] Don't special case symbolic relocations with 0 addend to ifunc in ↵Fangrui Song2019-08-131-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | writable locations Currently the following 3 relocation types do not trigger the creation of a canonical PLT (which changes STT_GNU_IFUNC to STT_FUNC and redirects all references): 1) GOT-generating (`needsGot`) 2) PLT-generating (`needsPlt`) 3) R_ABS with 0 addend in a writable location. This is used for for ifunc function pointers in writable sections such as .data and .toc. This patch deletes case 3) to simplify the R_*_IRELATIVE generating logic added in D57371. Other advantages: * It is guaranteed no more than 1 R_*_IRELATIVE is created for an ifunc. * PPC64: no need to special case ifunc in toc-indirect to toc-relative relaxation. See D65755 The deleted elf::addIRelativeRelocs demonstrates that one-pass scan through relocations makes several optimizations difficult. This is something we can think about in the future. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D65995 llvm-svn: 368661
* [ELF] Rename odd variable names "New" after r365730. NFCFangrui Song2019-08-131-10/+10
| | | | | | | | | | New -> newSym or newFlags Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D66127 llvm-svn: 368651
* [ELF][AArch64] Support for movz, movk tprel relocationsPeter Smith2019-08-081-0/+10
| | | | | | | | | | | | | | | | | This patch Implements the R_AARCH64_TLSLE_MOVW_TPREL_G*[_NC]. These are logically the same calculation as the existing TLSLE relocations with the result written back to mov[nz] and movk instructions. A typical code sequence is: movz x0, #:tprel_g2:foo // bits [47:32] of R_TLS with overflow check movk x0, #:tprel_g1_nc:foo // bits [31:16] of R_TLS with no overflow check movk x0, #:tprel_g0_nc:foo // bits [15:0] of R_TLS with no overflow check This type of code sequence is usually used with a large code model. Differential Revision: https://reviews.llvm.org/D65882 Fixes: PR42853 llvm-svn: 368293
* [ELF][PPC] Don't relax ifunc toc-indirect accesses to toc-relativeFangrui Song2019-08-061-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Fixes PR42759. ``` // If ifunc is taken address in -fPIC code, it may have a toc entry .section .toc,"aw",@progbits .quad ifunc // ifunc may be defined as STT_GNU_IFUNC in another object file .type ifunc, %gnu_indirect_function ``` If ifunc is non-preemptable (e.g. when linking an executable), the toc entry will be relocated by R_PPC64_IRELATIVE. R_*_IRELATIVE represents the symbolic value of a non-preemptable ifunc (not associated with a canonical PLT) in a writable location. It has an unknown value at link time, so we cannot apply toc-indirect to toc-relative relaxation. Reviewed By: luporl, sfertile Differential Revision: https://reviews.llvm.org/D65755 llvm-svn: 368057
* [mips] Assign R_TLS type to the R_MIPS_TLS_TPREL_XXX relocations. NFCSimon Atanasyan2019-07-241-8/+4
| | | | | | | | That allows to remove duplicated code which subtracts 0x7000 from the R_MIPS_TLS_TPREL_XXX relocations values in the `MIPS::relocateOne` function. llvm-svn: 366888
* ELF: Add support for remaining R_AARCH64_MOVW* relocations.Peter Collingbourne2019-07-181-0/+60
| | | | | | Differential Revision: https://reviews.llvm.org/D64685 llvm-svn: 366466
* [ELF][PPC] Refactor some ppc64 testsFangrui Song2019-07-181-0/+1
| | | | | | | | Merge ppc64-dynamic-relocations.s into ppc64-plt-stub.s Add ppc64-tls-ie.s: covers ppc64-initial-exec-tls.s and ppc64-tls-ie-le.s Add ppc64-tls-gd.s: covers ppc64-general-dynamic-tls.s, ppc64-gd-to-ie.s, ppc64-tls-gd-le.s, and ppc64-tls-gd-le-small.s llvm-svn: 366424
* [ELF] Fix variable names in comments after VariableName -> variableName changeFangrui Song2019-07-163-9/+9
| | | | | | Also fix some typos. llvm-svn: 366181
* ELF: Add support for R_AARCH64_ADR_PREL_PG_HI21_NC relocation.Peter Collingbourne2019-07-101-0/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D64456 llvm-svn: 365662
* [Coding style change] Rename variables so that they start with a lowercase ↵Rui Ueyama2019-07-1014-2134/+2134
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | letter This patch is mechanically generated by clang-llvm-rename tool that I wrote using Clang Refactoring Engine just for creating this patch. You can see the source code of the tool at https://reviews.llvm.org/D64123. There's no manual post-processing; you can generate the same patch by re-running the tool against lld's code base. Here is the main discussion thread to change the LLVM coding style: https://lists.llvm.org/pipermail/llvm-dev/2019-February/130083.html In the discussion thread, I proposed we use lld as a testbed for variable naming scheme change, and this patch does that. I chose to rename variables so that they are in camelCase, just because that is a minimal change to make variables to start with a lowercase letter. Note to downstream patch maintainers: if you are maintaining a downstream lld repo, just rebasing ahead of this commit would cause massive merge conflicts because this patch essentially changes every line in the lld subdirectory. But there's a remedy. clang-llvm-rename tool is a batch tool, so you can rename variables in your downstream repo with the tool. Given that, here is how to rebase your repo to a commit after the mass renaming: 1. rebase to the commit just before the mass variable renaming, 2. apply the tool to your downstream repo to mass-rename variables locally, and 3. rebase again to the head. Most changes made by the tool should be identical for a downstream repo and for the head, so at the step 3, almost all changes should be merged and disappear. I'd expect that there would be some lines that you need to merge by hand, but that shouldn't be too many. Differential Revision: https://reviews.llvm.org/D64121 llvm-svn: 365595
* [LLD] NFC: Fixed GCC warning in ELF/Arch/RISCV.cppDenis Bakhvalov2019-07-091-1/+2
| | | | | | | | | GCC emits warning on this line: error: enumeral and non-enumeral type in conditional expression [-Werror=extra] Change-Id: I04969cc32e27e310968b88ebaa4e1c4894528d74 llvm-svn: 365434
* [ELF][RISCV] Support GD/LD/IE/LE TLS modelsFangrui Song2019-07-011-1/+35
| | | | | | | | | | | | RISC-V psABI doesn't specify TLS relaxation. It can be handled the same way as we handle ARM TLS. RISC-V TLS is even simpler because GD/LD use the same relocation type. Reviewed By: jrtc27, ruiu Differential Revision: https://reviews.llvm.org/D63220 llvm-svn: 364813
OpenPOWER on IntegriCloud