summaryrefslogtreecommitdiffstats
path: root/lld/ELF/Arch/AArch64.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [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
* [ELF] writePlt, writeIplt: replace parameters gotPltEntryAddr and index with ↵Fangrui Song2019-12-181-8/+10
| | | | | | | | | | `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-171-2/+5
| | | | | | | | | | | | | | | | | | | 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-161-6/+4
| | | | | | | | | | | | | | 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][AArch64] Support R_AARCH64_{CALL26,JUMP26} range extension thunks with ↵Fangrui Song2019-12-021-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ELF] Wrap things in `namespace lld { namespace elf {`, NFCFangrui Song2019-10-071-4/+8
| | | | | | | | | | | 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][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][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: 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] Fix variable names in comments after VariableName -> variableName changeFangrui Song2019-07-161-2/+2
| | | | | | 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-101-204/+204
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ELF][ARM][AARCH64][MIPS][PPC] Simplify the logic to create R_*_RELATIVE for ↵Fangrui Song2019-06-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Make the rule to create relative relocations in a writable section ↵Fangrui Song2019-06-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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][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
* [ELF] Delete GotEntrySize and GotPltEntrySizeFangrui Song2019-05-311-2/+0
| | | | | | | | | | | | | 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
* [LLD][ELF] - Improve diagnostic about unrecognized relocations.George Rimar2019-05-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [ELF] - Renamed few more AArch64 specific relocation expressions. NFC.George Rimar2018-11-151-2/+2
| | | | | | They are AArch64 only, so have to have AARCH64_* prefix. llvm-svn: 346963
* [ELF] - Renamed AArch64 specific relocations expressions. NFC.George Rimar2018-11-131-2/+2
| | | | | | They did not have AArch64 prefix. Now they do. llvm-svn: 346749
* [ELF] Refactor per-target TLS layout configuration. NFC.Ryan Prichard2018-10-311-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There are really three different kinds of TLS layouts: * A fixed TLS-to-TP offset. On architectures like PowerPC, MIPS, and RISC-V, the thread pointer points to a fixed offset from the start of the executable's TLS segment. The offset is 0x7000 for PowerPC and MIPS, which allows a signed 16-bit offset to reach 0x1000 of per-thread implementation data and 0xf000 of the application's TLS segment. The size and layout of the TCB isn't relevant to the static linker and might not be known. * A fixed TCB size. This is the format documented as "variant 1" in Ulrich Drepper's TLS spec. The thread pointer points to a 2-word TCB followed by the executable's TLS segment. The first word is always the DTV pointer. Used on ARM. The thread pointer must be aligned to the TLS segment's alignment, possibly creating alignment padding. * Variant 2. This format predates variant 1 and is also documented in Drepper's TLS spec. It allocates the executable's TLS segment before the thread pointer, apparently for backwards-compatibility. It's used on x86 and SPARC. Factor out an lld::elf::getTlsTpOffset() function for use in a follow-up patch for Android. The TcbSize/TlsTpOffset fields are only used in getTlsTpOffset, so replace them with a switch on Config->EMachine. Reviewers: espindola, ruiu, PkmX, jrtc27 Reviewed By: ruiu, PkmX, jrtc27 Subscribers: jyknight, emaste, sdardis, nemanjai, javed.absar, arichardson, kristof.beyls, kbarton, fedor.sergeev, atanasyan, PkmX, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D53905 llvm-svn: 345775
* [AArch64] Fix range check of R_AARCH64_TLSLE_ADD_TPREL_HI12Ryan Prichard2018-09-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: An AArch64 LE relocation is a positive ("variant 1") offset. This relocation is used to write the upper 12 bits of a 24-bit offset into an add instruction: add x0, x0, :tprel_hi12:v1 The comment in the ARM docs for R_AARCH64_TLSLE_ADD_TPREL_HI12 is: "Set an ADD immediate field to bits [23:12] of X; check 0 <= X < 2^24." Reviewers: javed.absar, espindola, ruiu, peter.smith, zatrazz Reviewed By: ruiu Subscribers: emaste, arichardson, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D52525 llvm-svn: 343144
* [ELF] - Do not fail on R_*_NONE relocations when parsing the debug info.George Rimar2018-09-261-0/+1
| | | | | | | | | | | | | | | | | This is https://bugs.llvm.org//show_bug.cgi?id=38919. Currently, LLD may report "unsupported relocation target while parsing debug info" when parsing the debug information. At the same time LLD does that for zeroed R_X86_64_NONE relocations, which obviously has "invalid" targets. The nature of R_*_NONE relocation assumes them should be ignored. This patch teaches LLD to stop reporting the debug information parsing errors for them. Differential revision: https://reviews.llvm.org/D52408 llvm-svn: 343078
* Reset input section pointers to null on each linker invocation.Rui Ueyama2018-09-251-3/+3
| | | | | | | | | | Previously, if you invoke lld's `main` more than once in the same process, the second invocation could fail or produce a wrong result due to a stale pointer values of the previous run. Differential Revision: https://reviews.llvm.org/D52506 llvm-svn: 343009
* Align AArch64 and i386 image base to superpageDimitry Andric2018-09-211-0/+4
| | | | | | | | | | | | | | | | | | | Summary: As for x86_64, the default image base for AArch64 and i386 should be aligned to a superpage appropriate for the architecture. On AArch64, this is 2 MiB, on i386 it is 4 MiB. Reviewers: emaste, grimar, javed.absar, espindola, ruiu, peter.smith, srhines, rprichard Reviewed By: ruiu, peter.smith Subscribers: jfb, markj, arichardson, krytarowski, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D50297 llvm-svn: 342746
* [ELF] Add support for Armv5 and Armv6 compatible ThunksPeter Smith2018-08-201-5/+8
| | | | | | | | | | | | | | | | Older Arm architectures do not support the MOVT and MOVW instructions so we must use an alternative sequence of instructions to transfer control to the destination. Assuming at least Armv5 this patch adds support for Thunks that load or add to the program counter. Note that there are no Armv5 Thumb Thunks as there is no Thumb branch instruction in Armv5 that supports Thunks. These thunks will not work for Armv4t (arm7tdmi) as this architecture cannot change state from using the LDR or ADD instruction. Differential Revision: https://reviews.llvm.org/D50077 llvm-svn: 340160
* [ELF][AArch64] Implement the AArch64 TLSLD_LDST_LO12 family of relocsPeter Smith2018-05-041-0/+10
| | | | | | | | | | | | | | | | | 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
* [LLD][AArch64] Simplify relocations sharing same encoding [NFC]Peter Smith2018-05-031-6/+3
| | | | | | | | | | | | | | | 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
* [ELF] - Eliminate Target::isPicRel method.George Rimar2018-04-051-3/+5
| | | | | | | | | | | | | | | | | | | | | | 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
* Do not use template for check{Int,UInt,IntUInt,Alignment}.Rui Ueyama2018-03-291-16/+16
| | | | | | | | Template is just unnecessary. Differential Revision: https://reviews.llvm.org/D45063 llvm-svn: 328843
* [ELF][AArch64] Add support for AArch64 range thunks.Peter Smith2017-11-291-0/+34
| | | | | | | | | | | | 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
* Rename SymbolBody -> SymbolRui Ueyama2017-11-031-4/+4
| | | | | | | | | | | | | 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
* [lld] unified COFF and ELF error handling on new Common/ErrorHandlerBob Haarman2017-10-251-1/+1
| | | | | | | | | | | | | | | | | | | 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
* Remove one parameter from Target::getRelExpr.Rui Ueyama2017-10-121-4/+4
| | | | | | | | 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
* Define RelType to represent relocation types.Rui Ueyama2017-10-111-16/+16
| | | | | | | | | | | | | | | | | | 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
* [AArch64] Properly check alignment for AARCH64_LD_PREL_LO19.Davide Italiano2017-09-211-0/+1
| | | | | | Follow-up suggested by Peter Smith. llvm-svn: 313850
* [AArch64] Implement R_AARCH64_ LD_PREL_LO19.Davide Italiano2017-09-201-0/+2
| | | | | | | | Fixes PR34660. Differential Revision: https://reviews.llvm.org/D38053 llvm-svn: 313841
* [ELF] Always write non-immediate bits for AArch64 branch instruction.Peter Smith2017-09-071-1/+10
| | | | | | | | | | | | 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
* [ELF][AArch64] Add alignment checks for the LDST<N>_ABS_LO12_NC relocationsPeter Smith2017-09-061-0/+4
| | | | | | | | | | | | | | | | | 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
* Fix which file is in an error message.Rafael Espindola2017-08-041-2/+2
| | | | | | | When reporting an invalid relocation we were blaming the destination file instead of the file with the relocation. llvm-svn: 310084
* Do not use make<> to allocate TargetInfo. NFC.Rui Ueyama2017-06-161-2/+4
| | | | llvm-svn: 305577
* Split Target.cpp into small files.Rui Ueyama2017-06-161-0/+374
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
OpenPOWER on IntegriCloud