summaryrefslogtreecommitdiffstats
path: root/lld/ELF/Arch
Commit message (Collapse)AuthorAgeFilesLines
...
* [ELF][RISCV] Support PLT, GOT, copy and relative relocationsFangrui Song2019-07-011-3/+117
| | | | | | | | | | | | | | | | | | | | * Handle initial relocation types: R_RISCV_CALL_PLT and R_RISCV_GOT_HI20. * Produce dynamic relocation types: R_RISCV_COPY, R_RISCV_RELATIVE, R_RISCV_JUMP_SLOT. * Define SymbolRel as R_RISCV_{32,64} * Generate PLT header: it is used by lazy binding PLT in glibc. * R_RISCV_CALL is changed from R_PC to R_PC_PLT. If the target symbol is preemptable, this will suppress an unnecessary "canonical PLT". This behavior is different from ld.bfd but it is agreed the current lld behavior is favored. I have received positive responses from the binutils maintainer that the ABI/binutils implementation can be improved, see: https://github.com/riscv/riscv-elf-psabi-doc/issues/98 https://sourceware.org/bugzilla/show_bug.cgi?id=24685 Many -no-pie/-pie/-shared programs linked against musl or glibc should work with this patch. Reviewed By: jrtc27 Differential Revision: https://reviews.llvm.org/D63076 llvm-svn: 364812
* [ELF][PPC][X86] Use [-2**(n-1), 2**n) to check overflows for R_PPC_ADDR16, ↵Fangrui Song2019-06-243-5/+14
| | | | | | | | | | | | | | | | | | | | | R_PPC64_ADDR{16,32}, R_X86_64_{8,16} Similar to R_AARCH64_ABS32, R_PPC64_ADDR32 can represent either a signed value or unsigned value, thus we should use `[-2**(n-1), 2**n)` instead of `[-2**(n-1), 2**(n-1))` to check overflows. The issue manifests as a bogus linker error when linking the powerpc64le Linux kernel. The new behavior is compatible with ld.bfd's complain_overflow_bitfield. The upper bound of the error message is not correct. Fix it as well. The changes to R_PPC_ADDR16, R_PPC64_ADDR16, R_X86_64_8 and R_X86_64_16 are similar. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D63690 llvm-svn: 364164
* [ELF][ARM][AARCH64][MIPS][PPC] Simplify the logic to create R_*_RELATIVE for ↵Fangrui Song2019-06-205-5/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | absolute relocation types in writable sections Summary: Our rule to create R_*_RELATIVE for absolute relocation types were loose. D63121 made it stricter but it failed to create R_*_RELATIVE for R_ARM_TARGET1 and R_PPC64_TOC. rLLD363236 worked around that by reinstating the original behavior for ARM and PPC64. This patch is an attempt to simplify the logic. Note, in ld.bfd, R_ARM_TARGET2 --target2=abs also creates R_ARM_RELATIVE. This seems a very uncommon scenario (moreover, --target2=got-rel is the default), so I do not implement any logic related to it. Also, delete R_AARCH64_ABS32 from AArch64::getDynRel. We don't have working ILP32 support yet. Allowing it would create an incorrect R_AARCH64_RELATIVE. For MIPS, the (if SymbolRel, then RelativeRel) code is to keep its behavior unchanged. Note, in ppc64-abs64-dyn.s, R_PPC64_TOC gets an incorrect addend because computeAddend() doesn't compute the correct address. We seem to have the wrong behavior for a long time. The important thing seems that a dynamic relocation R_PPC64_TOC should not be created as the dynamic loader will error R_PPC64_TOC is not supported. Reviewers: atanasyan, grimar, peter.smith, ruiu, sfertile, espindola Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D63383 llvm-svn: 363928
* [ELF][ARM] Merge handleARMTlsRelocation() into handleTlsRelocation()Fangrui Song2019-06-201-3/+0
| | | | | | | | | | | | | | | | | | | | | | | ARM and RISC-V do not support TLS relaxations. However, for General Dynamic and Local Dynamic models, if we are producing an executable and the symbol is non-preemptable, we know it must be defined and the R_ARM_TLS_DTPMOD32/R_RISCV_TLS_DTPMOD{32,64} dynamic relocation can be omitted because it is always 1. This may be necessary for static linking as DTPMOD may not be expected at load time. Merge handleARMTlsRelocation() into handleTlsRelocation(). This requires more logic to R_TLSGD_PC and R_TLSLD_PC. Because we use SymbolicRel to resolve the relocation at link time, R_ARM_TLS_DTPMOD32 can be deleted from relocateOne(). It cannot be used as a static relocation type. As a bonus, the additional logic in R_TLSGD_PC code can be shared by the TLS support for RISC-V (D63220). Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D63333 llvm-svn: 363927
* [ELF][RISCV] Treat R_RISCV_{ADD,SET,SUB}* as link-time constantsFangrui Song2019-06-121-0/+14
| | | | | | | | | | | | | | | | | | | | | | | R_RISCV_{ADD,SET,SUB}* are used for local label computation. Add a new RelExpr member R_RISCV_ADD to represent them. R_RISCV_ADD is treated as a link-time constant because otherwise R_RISCV_{ADD,SET,SUB}* are not allowed in -pie/-shared mode. In glibc Scrt1.o, .rela.eh_frame contains such relocations. Because .eh_frame is not writable, we get this error: ld.lld: error: can't create dynamic relocation R_RISCV_ADD32 against symbol: .L0 in readonly segment; recompil object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in ..../riscv64-linux-gnu/lib/Scrt1.o With D63076 and this patch, I can run -pie/-shared programs linked against glibc. Note llvm-mc cannot currently produce R_RISCV_SET* so they are not tested. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D63183 llvm-svn: 363128
* Revert "Revert r362867: [ELF][PPC] Simplify {read,write}FromHalf16"Fangrui Song2019-06-122-30/+31
| | | | | | | | | | | | | | | This reverts commit r363060 and restores r362867. r362867 is innocent. The ppc64le-lld-multistage-test bot failure was due to a clang/gcc .toc bug: ld.lld: error: relocation refers to a discarded section: .rodata._ZNK4llvm3MVT13getSizeInBitsEv >>> defined in utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenRegisters.cpp.o >>> referenced by CodeGenRegisters.cpp >>> utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenRegisters.cpp.o:(.toc+0x0) It will be worked around by D63182. llvm-svn: 363124
* Revert r362867: [ELF][PPC] Simplify {read,write}FromHalf16Rui Ueyama2019-06-112-31/+30
| | | | | | | This reverts commit r362867 since it seems to have broken ppc64le-lld-multistage-test bot. llvm-svn: 363060
* [ELF] Make the rule to create relative relocations in a writable section ↵Fangrui Song2019-06-1110-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | stricter The current rule is loose: `!Sym.IsPreemptible || Expr == R_GOT`. When the symbol is non-preemptable, this allows absolute relocation types with smaller numbers of bits, e.g. R_X86_64_{8,16,32}. They are disallowed by ld.bfd and gold, e.g. ld.bfd: a.o: relocation R_X86_64_8 against `.text' can not be used when making a shared object; recompile with -fPIC This patch: a) Add TargetInfo::SymbolicRel to represent relocation types that resolve to a symbol value (e.g. R_AARCH_ABS64, R_386_32, R_X86_64_64). As a side benefit, we currently (ab)use GotRel (R_*_GLOB_DAT) to resolve GOT slots that are link-time constants. Since we now use Target->SymbolRel to do the job, we can remove R_*_GLOB_DAT from relocateOne() for all targets. R_*_GLOB_DAT cannot be used as static relocation types. b) Change the condition to `!Sym.IsPreemptible && Type != Target->SymbolicRel || Expr == R_GOT`. Some tests are caught by the improved error checking (ld.bfd/gold also issue errors on them). Many misuse .long where .quad should be used instead. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D63121 llvm-svn: 363059
* [ELF] [PPC] Fix a typo from SVN r362721Martin Storsjo2019-06-081-1/+1
| | | | | | | Apparently no test covers this exact codepath, but GCC produced a warning about it. llvm-svn: 362883
* [ELF][PPC] Simplify {read,write}FromHalf16Fangrui Song2019-06-082-30/+31
| | | | | | | | | | | | | | | I've change the variable names used in PPC64.cpp from "Instr" to "Insn" because "Insn" is a more common abbreviation for "instruction". While changing PPC64.cpp relocateOne(), make R_PPC64_ADDR16_LO{_DS} slightly more efficient by saving a read and a write for the TocOptimize case. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D63043 llvm-svn: 362867
* ELF: Create synthetic sections for loadable partitions.Peter Collingbourne2019-06-073-3/+3
| | | | | | | | | | | | | | | We create several types of synthetic sections for loadable partitions, including: - The dynamic symbol table. This allows code outside of the loadable partitions to find entry points with dlsym. - Creating a dynamic symbol table also requires the creation of several other synthetic sections for the partition, such as the dynamic table and hash table sections. - The partition's ELF header is represented as a synthetic section in the combined output file, and will be used by llvm-objcopy to extract partitions. Differential Revision: https://reviews.llvm.org/D62350 llvm-svn: 362819
* [ELF][AArch64] Support for BTI and PACPeter Smith2019-06-071-4/+154
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Branch Target Identification (BTI) and Pointer Authentication (PAC) are architecture features introduced in v8.5a and 8.3a respectively. The new instructions have been added in the hint space so that binaries take advantage of support where it exists yet still run on older hardware. The impact of each feature is: BTI: For executable pages that have been guarded, all indirect branches must have a destination that is a BTI instruction of the appropriate type. For the static linker, this means that PLT entries must have a "BTI c" as the first instruction in the sequence. BTI is an all or nothing property for a link unit, any indirect branch not landing on a valid destination will cause a Branch Target Exception. PAC: The dynamic loader encodes with PACIA the address of the destination that the PLT entry will load from the .plt.got, placing the result in a subset of the top-bits that are not valid virtual addresses. The PLT entry may authenticate these top-bits using the AUTIA instruction before branching to the destination. Use of PAC in PLT sequences is a contract between the dynamic loader and the static linker, it is independent of whether the relocatable objects use PAC. BTI and PAC are independent features that can be combined. So we can have several combinations of PLT: - Standard with no BTI or PAC - BTI PLT with "BTI c" as first instruction. - PAC PLT with "AUTIA1716" before the indirect branch to X17. - BTIPAC PLT with "BTI c" as first instruction and "AUTIA1716" before the first indirect branch to X17. The use of BTI and PAC in relocatable object files are encoded by feature bits in the .note.gnu.property section in a similar way to Intel CET. There is one AArch64 specific program property GNU_PROPERTY_AARCH64_FEATURE_1_AND and two target feature bits defined: - GNU_PROPERTY_AARCH64_FEATURE_1_BTI -- All executable sections are compatible with BTI. - GNU_PROPERTY_AARCH64_FEATURE_1_PAC -- All executable sections have return address signing enabled. Due to the properties of FEATURE_1_AND the static linker can tell when all input relocatable objects have the BTI and PAC feature bits set. The static linker uses this to enable the appropriate PLT sequence. Neither -> standard PLT GNU_PROPERTY_AARCH64_FEATURE_1_BTI -> BTI PLT GNU_PROPERTY_AARCH64_FEATURE_1_PAC -> PAC PLT Both properties -> BTIPAC PLT In addition to the .note.gnu.properties there are two new command line options: --force-bti : Act as if all relocatable inputs had GNU_PROPERTY_AARCH64_FEATURE_1_BTI and warn for every relocatable object that does not. --pac-plt : Act as if all relocatable inputs had GNU_PROPERTY_AARCH64_FEATURE_1_PAC. As PAC is a contract between the loader and static linker no warning is given if it is not present in an input. Two processor specific dynamic tags are used to communicate that a non standard PLT sequence is being used. DTI_AARCH64_BTI_PLT and DTI_AARCH64_BTI_PAC. Differential Revision: https://reviews.llvm.org/D62609 llvm-svn: 362793
* [PPC32] Support GD/LD/IE/LE TLS models and their relaxationsFangrui Song2019-06-062-4/+189
| | | | | | | | Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D62940 llvm-svn: 362722
* [PPC32] Improve the 32-bit PowerPC portFangrui Song2019-06-061-11/+170
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many -static/-no-pie/-shared/-pie applications linked against glibc or musl should work with this patch. This also helps FreeBSD PowerPC64 to migrate their lib32 (PR40888). * Fix default image base and max page size. * Support new-style Secure PLT (see below). Old-style BSS PLT is not implemented, so it is not suitable for FreeBSD rtld now because it doesn't support Secure PLT yet. * Support more initial relocation types: R_PPC_ADDR32, R_PPC_REL16*, R_PPC_LOCAL24PC, R_PPC_PLTREL24, and R_PPC_GOT16. The addend of R_PPC_PLTREL24 is special: it decides the call stub PLT type but it should be ignored for the computation of target symbol VA. * Support GNU ifunc * Support .glink used for lazy PLT resolution in glibc * Add a new thunk type: PPC32PltCallStub that is similar to PPC64PltCallStub. It is used by R_PPC_REL24 and R_PPC_PLTREL24. A PLT stub used in -fPIE/-fPIC usually loads an address relative to .got2+0x8000 (-fpie/-fpic code uses _GLOBAL_OFFSET_TABLE_ relative addresses). Two .got2 sections in two object files have different addresses, thus a PLT stub can't be shared by two object files. To handle this incompatibility, change the parameters of Thunk::isCompatibleWith to `const InputSection &, const Relocation &`. PowerPC psABI specified an old-style .plt (BSS PLT) that is both writable and executable. Linkers don't make separate RW- and RWE segments, which causes all initially writable memory (think .data) executable. This is a big security concern so a new PLT scheme (secure PLT) was developed to address the security issue. TLS will be implemented in D62940. glibc older than ~2012 requires .rela.dyn to include .rela.plt, it can not handle the DT_RELA+DT_RELASZ == DT_JMPREL case correctly. A hack (not included in this patch) in LinkerScript.cpp addOrphanSections() to work around the issue: if (Config->EMachine == EM_PPC) { // Older glibc assumes .rela.dyn includes .rela.plt Add(In.RelaDyn); if (In.RelaPlt->isLive() && !In.RelaPlt->Parent) In.RelaDyn->getParent()->addSection(In.RelaPlt); } Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D62464 llvm-svn: 362721
* [ELF][PPC64] Rename some PPC64 ELFv2 specific RelExpr from R_PPC_* to R_PPC64_*Fangrui Song2019-06-031-2/+2
| | | | | | | | | | | | | | | | | | The following abstract relocation types (RelExpr) are PPC64 ELFv2 ABI specific, not used by PPC32. So rename them to prevent confusion when the PPC32 port is improved. * R_PPC_CALL R_PPC_CALL_PLT: R_PPC_CALL_PLT represents R_PPC64_REL14 and R_PPC64_REL24. If the function is not preemptable, R_PPC_CALL_PLT can be optimized to R_PPC_CALL: the formula adjusts the symbol VA from the global entry point to the local entry point. * R_PPC_TOC: represents R_PPC64_TOC. We don't have a test. Add one to ppc64-relocs.s Rename it to R_PPC64_TOCBASE because `@tocbase` is the assembly form. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D62800 llvm-svn: 362359
* [ELF][PPC64] Don't apply LD->LE relaxation on R_PPC64_GOT_DTPREL16*Fangrui Song2019-06-031-4/+0
| | | | | | | | | | | | | | In ELF v2 ABI, R_PPC64_GOT_DTPREL16* are not relaxed. This family of relocation types are used for variables outside of 2GiB of the TLS block. 2 instructions cannot materialize a DTPREL offset that is not 32-bit. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D62737 llvm-svn: 362357
* [ELF] Delete GotEntrySize and GotPltEntrySizeFangrui Song2019-05-319-16/+1
| | | | | | | | | | | | | GotEntrySize and GotPltEntrySize were added in D22288. Later, with the introduction of wordsize() (then Config->Wordsize), they become redundant, because there is no target that sets GotEntrySize or GotPltEntrySize to a number different from Config->Wordsize. Reviewed By: grimar, ruiu Differential Revision: https://reviews.llvm.org/D62727 llvm-svn: 362220
* [ELF] Implement General Dynamic style TLSDESC for x86-64Fangrui Song2019-05-291-36/+79
| | | | | | | | | | | This handles two initial relocation types R_X86_64_GOTPC32_TLSDESC and R_X86_64_TLSDESC_CALL, as well as the GD->LE and GD->IE relaxations. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D62513 llvm-svn: 361911
* [LLD][ELF] - Improve diagnostic about unrecognized relocations.George Rimar2019-05-237-7/+7
| | | | | | | | | | | | | | | | | | | | | | This is a minor improvement inspired by https://bugs.llvm.org/show_bug.cgi?id=38303. A person reported that he observed message complaining about unsupported R_ARM_V4BX: error: can't create dynamic relocation R_ARM_V4BX against local symbol in readonly segment; recompile object files with -fPIC But with -z notext he only saw a relocation number, what is not convenient: error: ../../gfx/cairo/libpixman/src/pixman-arm-neon-asm-bilinear.o:(.text+0x4F0): unrecognized reloc 40 Also, in the error messages we use relocation but not reloc. With this patch we start to print one of the following messages: error: file.o: unrecognized relocation Unknown(999) error: file.o: unrecognized relocation R_X_KNOWN_BY_LLVM_BUT_UNSUPPORTED_BY_LLD_NAME There is no way to write a test for that I believe. Differential revision: https://reviews.llvm.org/D62237 llvm-svn: 361472
* [ELF] Full support for -n (--nmagic) and -N (--omagic) via common pagePeter Smith2019-05-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | The -n (--nmagic) disables page alignment, and acts as a -Bstatic The -N (--omagic) does what -n does but also marks the executable segment as writeable. As page alignment is disabled headers are not allocated unless explicit in the linker script. To disable page alignment in LLD we choose to set the page sizes to 1 so that any alignment based on the page size does nothing. To set the Target->PageSize to 1 we implement -z common-page-size, which has the side effect of allowing the user to set the value as well. Setting the page alignments to 1 does mean that any use of CONSTANT(MAXPAGESIZE) or CONSTANT(COMMONPAGESIZE) in a linker script will return 1, unlike in ld.bfd. However given that -n and -N disable paging these probably shouldn't be used in a linker script where -n or -N is in use. Differential Revision: https://reviews.llvm.org/D61688 llvm-svn: 360593
* [PPC64] Define getThunkSectionSpacing() based on the range of R_PPC64_REL24Fangrui Song2019-05-101-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Suggested by Sean Fertile and Peter Smith. Thunk section spacing decrease the total number of thunks. I measured a decrease of 1% or less in some large programs, with no perceivable slowdown in link time. Override getThunkSectionSpacing() to enable it. 0x2000000 is the farthest point R_PPC64_REL24 can reach. I tried several numbers and found 0x2000000 works the best. Numbers near 0x2000000 work as well but let's just use the simpler number. As demonstrated by the updated tests, this essentially changes placement of most thunks to the end of the output section. We leverage this property to fix PR40740 reported by Alfredo Dal'Ava Júnior: The output section .init consists of input sections from several object files (crti.o crtbegin.o crtend.o crtn.o). Sections other than the last one do not have a terminator. With this patch, we create the thunk after the last .init input section and thus fix the issue. This is not foolproof but works quite well for such sections (with no terminator) in practice. Reviewed By: ruiu, sfertile Differential Revision: https://reviews.llvm.org/D61720 llvm-svn: 360405
* [mips] Fix ld instruction in PLT entries on MIPS64Simon Atanasyan2019-05-071-2/+4
| | | | | | | | | | | Use `ld` and `daddiu` instructions in MIPS64 PLT records. That fixes a segmentation fault. Patch by Qiao Pengcheng. Differential Revision: https://reviews.llvm.org/D61586 llvm-svn: 360187
* [PPC64] toc-indirect to toc-relative relaxationFangrui Song2019-05-072-4/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is based on D54720 by Sean Fertile. When accessing a global symbol which is not defined in the translation unit, compilers will generate instructions that load the address from the toc entry. If the symbol is defined, non-preemptable, and addressable with a 32-bit signed offset from the toc pointer, the address can be computed directly. e.g. addis 3, 2, .LC0@toc@ha # R_PPC64_TOC16_HA ld 3, .LC0@toc@l(3) # R_PPC64_TOC16_LO_DS, load the address from a .toc entry ld/lwa 3, 0(3) # load the value from the address .section .toc,"aw",@progbits .LC0: .tc var[TC],var can be relaxed to addis 3,2,var@toc@ha # this may be relaxed to a nop, addi 3,3,var@toc@l # then this becomes addi 3,2,var@toc ld/lwa 3, 0(3) # load the value from the address We can delete the test ppc64-got-indirect.s as its purpose is covered by newly added ppc64-toc-relax.s and ppc64-toc-relax-constants.s Reviewed By: ruiu, sfertile Differential Revision: https://reviews.llvm.org/D60958 llvm-svn: 360112
* [PPC64] Consider localentry offset when computing branch distanceFangrui Song2019-04-241-1/+4
| | | | | | | | | | | | | | | Summary: We don't take localentry offset into account, and thus may fail to create a long branch when the gap is just a few bytes smaller than 2^25. relocation R_PPC64_REL24 out of range: 33554432 is not in [-33554432, 33554431] relocation R_PPC64_REL24 out of range: 33554436 is not in [-33554432, 33554431] Fix that by adding the offset to the symbol VA. Differential Revision: https://reviews.llvm.org/D61058 llvm-svn: 359094
* [PPC64] Allow R_PPC64_DTPREL* to preemptable local-dynamic symbolsFangrui Song2019-04-231-1/+1
| | | | | | | | Similar to D60945. Differential Revision: https://reviews.llvm.org/D60994 llvm-svn: 358950
* [ELF][X86] Allow R_386_TLS_LDO_32 and R_X86_64_DTPOFF{32,64} to preemptable ↵Fangrui Song2019-04-222-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | local-dynamic symbols Summary: Fixes PR35242. A simplified reproduce: thread_local int i; int f() { return i; } % {g++,clang++} -fPIC -shared -ftls-model=local-dynamic -fuse-ld=lld a.cc ld.lld: error: can't create dynamic relocation R_X86_64_DTPOFF32 against symbol: i in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output In isStaticLinkTimeConstant(), Syn.IsPreemptible is true, so it is not seen as a constant. The error is then issued in processRelocAux(). A symbol of the local-dynamic TLS model cannot be preempted but it can preempt symbols of the global-dynamic TLS model in other DSOs. So it makes some sense that the variable is not static. This patch fixes the linking error by changing getRelExpr() on R_386_TLS_LDO_32 and R_X86_64_DTPOFF{32,64} from R_ABS to R_DTPREL. R_PPC64_DTPREL_* and R_MIPS_TLS_DTPREL_* need similar fixes, but they are not handled in this patch. As a bonus, we use `if (Expr == R_ABS && !Config->Shared)` to find ld-to-le opportunities. R_ABS is overloaded here for such STT_TLS symbols. A dedicated R_DTPREL is clearer. Differential Revision: https://reviews.llvm.org/D60945 llvm-svn: 358870
* [ELF][X86] Rename R_RELAX_TLS_GD_TO_IE_END to R_RELAX_TLS_GD_TO_IE_GOTPLTFangrui Song2019-04-221-1/+1
| | | | | | | | | | Summary: This relocation type is used by R_386_TLS_GD. Its formula is the same as R_GOTPLT (e.g R_X86_64_GOT{32,64} R_386_TLS_GOTIE). Rename it to be clearer. Differential Revision: https://reviews.llvm.org/D60941 llvm-svn: 358868
* [RISCV] Fix range check for HI20/LO12/RVC_LUI relocationsChih-Mao Chen2019-04-091-12/+13
| | | | | | | | | | | | | | | | | The code previously specified a 32-bit range for R_RISCV_HI20 and R_RISCV_LO12_[IS], however this is incorrect as the maximum offset on RV64 that can be formed from the immediate of lui and the displacement of an I-type or S-type instruction is -0x80000800 to 0x7ffff7ff. There is also the same issue with a c.lui and LO12 pair, whose actual addressable range should be -0x20800 to 0x1f7ff. The tests will be included in the next patch that converts all RISC-V tests to use llvm-mc instead of yaml2obj, as assembler support has matured enough to write tests in them. Differential Revision: https://reviews.llvm.org/D60414 llvm-svn: 357995
* ELF: De-template ELFFileBase. NFCI.Peter Collingbourne2019-04-052-3/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D60304 llvm-svn: 357806
* Simplify. NFC.Rui Ueyama2019-04-011-13/+13
| | | | llvm-svn: 357373
* Create an instance of Target after reading all input files. NFC.Rui Ueyama2019-03-282-2/+0
| | | | | | | | This change itself doesn't mean anything, but it helps D59780 because in patch, we don't know whether we need to create a CET-aware PLT or not until we read all input files. llvm-svn: 357194
* Make a member function a non-member function.Rui Ueyama2019-03-281-6/+2
| | | | | | | Since this member function doesn't use anything in the class, it doesn't have to be a member of the class. llvm-svn: 357193
* De-template X86_64TargetInfo. NFC.Rui Ueyama2019-03-281-87/+54
| | | | llvm-svn: 357191
* Inline a trivial function. NFC.Rui Ueyama2019-03-283-7/+7
| | | | | | | I found that hiding this particular actual expression doesn't help readers understand the code. So I remove and inline that function. llvm-svn: 357140
* [ELF] Change GOT*_FROM_END (relative to end(.got)) to GOTPLT* (start(.got.plt))Fangrui Song2019-03-252-26/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This should address remaining issues discussed in PR36555. Currently R_GOT*_FROM_END are exclusively used by x86 and x86_64 to express relocations types relative to the GOT base. We have _GLOBAL_OFFSET_TABLE_ (GOT base) = start(.got.plt) but end(.got) != start(.got.plt) This can have problems when _GLOBAL_OFFSET_TABLE_ is used as a symbol, e.g. glibc dl_machine_dynamic assumes _GLOBAL_OFFSET_TABLE_ is start(.got.plt), which is not true. extern const ElfW(Addr) _GLOBAL_OFFSET_TABLE_[] attribute_hidden; return _GLOBAL_OFFSET_TABLE_[0]; // R_X86_64_GOTPC32 In this patch, we * Change all GOT*_FROM_END to GOTPLT* to fix the problem. * Add HasGotPltOffRel to denote whether .got.plt should be kept even if the section is empty. * Simplify GotSection::empty and GotPltSection::empty by setting HasGotOffRel and HasGotPltOffRel according to GlobalOffsetTable early. The change of R_386_GOTPC makes X86::writePltHeader simpler as we don't have to compute the offset start(.got.plt) - Ebx (it is constant 0). We still diverge from ld.bfd (at least in most cases) and gold in that .got.plt and .got are not adjacent, but the advantage doing that is unclear. Reviewers: ruiu, sivachandra, espindola Subscribers: emaste, mehdi_amini, arichardson, dexonsmith, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59594 llvm-svn: 356968
* [mips] Create LA25 thunks for MIPS R6 codeSimon Atanasyan2019-02-191-2/+2
| | | | | | | | MIPS R6 code uses the `R_MIPS_PC26_S2` relocation for calls which might cross boundaries of non-PIC-to-PIC code. We need to create a LA25 thunks for that case. llvm-svn: 354312
* [MIPS] Handle cross-mode (regular <-> microMIPS) jumpsSimon Atanasyan2019-02-191-0/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch solves two tasks: 1. MIPS ABI allows to mix regular and microMIPS code and perform cross-mode jumps. Linker needs to detect such cases and replace jump/branch instructions by their cross-mode equivalents. 2. Other tools like dunamic linkers need to recognize cases when dynamic table entries, e_entry field of an ELF header etc point to microMIPS symbol. Linker should provide such information. The first task is implemented in the `MIPS<ELFT>::relocateOne()` method. New routine `fixupCrossModeJump` detects ISA mode change, checks and replaces an instruction. The main problem is how to recognize that relocation target is microMIPS symbol. For absolute and section symbols compiler or assembler set the less-significant bit of the symbol's value or sum of the symbol's value and addend. And this bit signals to linker about microMIPS code. For global symbols compiler cannot do the same trick because other tools like, for example, disassembler wants to know an actual position of the symbol. So compiler sets STO_MIPS_MICROMIPS flag in the `st_other` field. In `MIPS<ELFT>::relocateOne()` method we have a symbol's value only and cannot access any symbol's attributes. To pass type of the symbol (regular/microMIPS) to that routine as well as other places where we write a symbol value as-is (.dynamic section, `Elf_Ehdr::e_entry` field etc) we set when necessary a less-significant bit in the `getSymVA` function. Differential revision: https://reviews.llvm.org/D40147 llvm-svn: 354311
* Improve error message for unknown relocations.Rui Ueyama2019-02-145-10/+20
| | | | | | | | | | | | Previously, we showed the following message for an unknown relocation: foo.o: unrecognized reloc 256 This patch improves it so that the error message includes a symbol name: foo.o: unknown relocation (256) against symbol bar llvm-svn: 354040
* [PPC64] Sort .toc sections accessed with small code model relocs.Sean Fertile2019-02-121-7/+3
| | | | | | | | | | | | | A follow up to the intial patch that unblocked linking against libgcc. For lld we don't need to bother tracking which objects have got based small code model relocations. This is due to the fact that the compilers on powerpc64 use the .toc section to generate indirections to symbols (rather then using got relocations) which keeps the got small. This makes overflowing a small code model got relocation very unlikely. Differential Revision: https://reviews.llvm.org/D57245 llvm-svn: 353849
* Fix a bug in R_X86_64_PC{8,16} relocation handling.Rui Ueyama2019-02-071-2/+8
| | | | | | | | R_X86_64_PC{8,16} relocations are sign-extended, so when we check for relocation overflow, we had to use checkInt instead of checkUInt. I confirmed that GNU linkers create the same output for the test case. llvm-svn: 353437
* [LLD][ELF] - Set DF_STATIC_TLS flag for X64 targetGeorge Rimar2019-02-071-0/+3
| | | | | | | | | | | | This is the same as D57749, but for x64 target. "ELF Handling For Thread-Local Storage" p41 says (https://www.akkadia.org/drepper/tls.pdf): R_X86_64_GOTTPOFF relocation is used for IE TLS models. Hence if linker sees this relocation we should add DF_STATIC_TLS flag. Differential revision: https://reviews.llvm.org/D57821 llvm-svn: 353378
* Support R_X86_64_PC8 and R_X86_64_PC16.Rui Ueyama2019-02-061-0/+4
| | | | | | | | They are defined by the x86-64 ELF ABI standard. Differential Revision: https://reviews.llvm.org/D57799 llvm-svn: 353314
* Recommit r353293 "[LLD][ELF] - Set DF_STATIC_TLS flag for i386 target."George Rimar2019-02-061-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the following changes: 1) Compilation fix: std::atomic<bool> HasStaticTlsModel = false; -> std::atomic<bool> HasStaticTlsModel{false}; 2) Adjusted the comment in code. Initial commit message: DF_STATIC_TLS flag indicates that the shared object or executable contains code using a static thread-local storage scheme. Patch checks if IE/LE relocations were used to check if the code uses a static model. If so it sets the DF_STATIC_TLS flag. Differential revision: https://reviews.llvm.org/D57749 ---- Modified : /lld/trunk/ELF/Arch/X86.cpp Modified : /lld/trunk/ELF/Config.h Modified : /lld/trunk/ELF/SyntheticSections.cpp Added : /lld/trunk/test/ELF/Inputs/i386-static-tls-model1.s Added : /lld/trunk/test/ELF/Inputs/i386-static-tls-model2.s Added : /lld/trunk/test/ELF/Inputs/i386-static-tls-model3.s Added : /lld/trunk/test/ELF/Inputs/i386-static-tls-model4.s Added : /lld/trunk/test/ELF/i386-static-tls-model.s Modified : /lld/trunk/test/ELF/i386-tls-ie-shared.s Modified : /lld/trunk/test/ELF/tls-dynamic-i686.s Modified : /lld/trunk/test/ELF/tls-opt-iele-i686-nopic.s llvm-svn: 353299
* Revert r353293 "[LLD][ELF] - Set DF_STATIC_TLS flag for i386 target."George Rimar2019-02-061-9/+0
| | | | | | | | | | | | It broke BB: http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/43450 http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/27891 Error is: tools/lld/ELF/Config.h:84:41: error: copying member subobject of type 'std::atomic<bool>' invokes deleted constructor std::atomic<bool> HasStaticTlsModel = false; llvm-svn: 353297
* [LLD][ELF] - Set DF_STATIC_TLS flag for i386 target.George Rimar2019-02-061-0/+9
| | | | | | | | | | | | DF_STATIC_TLS flag indicates that the shared object or executable contains code using a static thread-local storage scheme. Patch checks if IE/LE relocations were used to check if the code uses a static model. If so it sets the DF_STATIC_TLS flag. Differential revision: https://reviews.llvm.org/D57749 llvm-svn: 353293
* [PPC64] Set the number of relocations processed for R_PPC64_TLS[GL]D to 2Fangrui Song2019-02-063-2/+26
| | | | | | | | | | | | | | | | | | | | | | Summary: R_PPC64_TLSGD and R_PPC64_TLSLD are used as markers on TLS code sequences. After GD-to-IE or GD-to-LE relaxation, the next relocation R_PPC64_REL24 should be skipped to not create a false dependency on __tls_get_addr. When linking statically, the false dependency may cause an "undefined symbol: __tls_get_addr" error. R_PPC64_GOT_TLSGD16_HA R_PPC64_GOT_TLSGD16_LO R_PPC64_TLSGD R_TLSDESC_CALL R_PPC64_REL24 __tls_get_addr Reviewers: ruiu, sfertile, syzaara, espindola Reviewed By: sfertile Subscribers: emaste, nemanjai, arichardson, kbarton, jsji, llvm-commits, tamur Tags: #llvm Differential Revision: https://reviews.llvm.org/D57673 llvm-svn: 353262
* Inline a trivial function and update comment. NFC.Rui Ueyama2019-02-051-9/+7
| | | | llvm-svn: 353200
* [PPC64] Reland r351978 'Sort .toc sections accessed with small code model ...'Sean Fertile2019-01-241-0/+9
| | | | | | | | | | | | | | | | | | | | | | | Guessing that the slashes used in the scripts SECTION command was causing the windows related failures in the added test. Original commit message: Small code model global variable access on PPC64 has a very limited range of addressing. The instructions the relocations are used on add an offset in the range [-0x8000, 0x7FFC] to the toc pointer which points to .got +0x8000, giving an addressable range of [.got, .got + 0xFFFC]. While user code can be recompiled with medium and large code models when the binary grows too large for small code model, there are small code model relocations in the crt files and libgcc.a which are typically shipped with the distros, and the ABI dictates that linkers must allow linking of relocatable object files using different code models. To minimze the chance of relocation overflow, any file that contains a small code model relocation should have its .toc section placed closer to the .got then any .toc from a file without small code model relocations. Differential Revision: https://reviews.llvm.org/D56920 llvm-svn: 352071
* Revert "[PPC64] Sort .toc sections accessed with small code model ..."Sean Fertile2019-01-231-9/+0
| | | | | | | This reverts commit ca87c57a3aa4770c9cf0defd4b2feccbc342ee93. Added test fails on several windows buildbots. llvm-svn: 351985
* [PPC64] Sort .toc sections accessed with small code model relocs close to .got.Sean Fertile2019-01-231-0/+9
| | | | | | | | | | | | | | | | | | | Small code model global variable access on PPC64 has a very limited range of addressing. The instructions the relocations are used on add an offset in the range [-0x8000, 0x7FFC] to the toc pointer which points to .got +0x8000, giving an addressable range of [.got, .got + 0xFFFC]. While user code can be recompiled with medium and large code models when the binary grows too large for small code model, there are small code model relocations in the crt files and libgcc.a which are typically shipped with the distros, and the ABI dictates that linkers must allow linking of relocatable object files using different code models. To minimze the chance of relocation overflow, any file that contains a small code model relocation should have its .toc section placed closer to the .got then any .toc from a file without small code model relocations. Differential Revision: https://reviews.llvm.org/D56920 llvm-svn: 351978
OpenPOWER on IntegriCloud