summaryrefslogtreecommitdiffstats
path: root/lld/ELF/Arch/ARM.cpp
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] 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] writePlt, writeIplt: replace parameters gotPltEntryAddr and index with ↵Fangrui Song2019-12-181-6/+6
| | | | | | | | | | `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-1/+2
| | | | | | | | | | | | | | | | | | | 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-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-3/+7
| | | | | | | | | | | 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] Fix variable names in comments after VariableName -> variableName changeFangrui Song2019-07-161-6/+6
| | | | | | Also fix some typos. llvm-svn: 366181
* [Coding style change] Rename variables so that they start with a lowercase ↵Rui Ueyama2019-07-101-219/+219
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] 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] 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] 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] Fix ARM and Thumb V7PILongThunk overflow behavior.Peter Smith2019-01-101-2/+0
| | | | | | | | | | | | | | | | | | When the range between the source and target of a V7PILongThunk exceeded an int32 we would trigger a relocation out of range error for the R_ARM_MOVT_PREL or R_ARM_THM_MOVT_PREL relocation. This case can happen when linking the linux kernel as it is loaded above 0xf0000000. There are two parts to the fix. - Remove the overflow check for R_ARM_MOVT_PREL or R_ARM_THM_MOVT_PREL. The ELF for the ARM Architecture document defines these relocations as having no overflow checking so the check was spurious. - Use int64_t for the offset calculation, in line with similar thunks so that PC + (S - P) < 32-bits. This results in less surprising disassembly. Differential Revision: https://reviews.llvm.org/D56396 llvm-svn: 350836
* ELF: Handle R_ARM_V4BX correctly in PIC output files.Peter Collingbourne2018-12-151-6/+6
| | | | | | | | | | | | | | | Previously we considered R_ARM_V4BX to be an absolute relocation, which meant that we rejected it in read-only sections in PIC output files. Instead, treat it as a hint relocation so that relocation processing ignores it entirely. Also fix a problem with the test case where it was never being run because it has a .yaml extension and we don't run tests with that extension. Differential Revision: https://reviews.llvm.org/D55728 llvm-svn: 349216
* Support ARM_V4BX relocationFangrui Song2018-11-161-0/+6
| | | | | | | | | | | | | | | | Summary: This patch implementation the handler for ARM_V4BX. This relocation is used by GNU runtime files and other armv4 applications. Patch by Yin Ma Reviewers: espindola, MaskRay, ruiu, peter.smith, pcc Reviewed By: ruiu Subscribers: yinma, pcc, peter.smith, MaskRay, rovka, efriedma, emaste, javed.absar, arichardson, kristof.beyls, chrib, llvm-commits Differential Revision: https://reviews.llvm.org/D53444 llvm-svn: 347077
* [ELF] Make TrapInstr and Filler byte arrays. NFC.Simon Atanasyan2018-11-141-6/+6
| | | | | | | | | | | | The uint32_t type does not clearly convey that these fields are interpreted in the target endianness. Converting them to byte arrays should make this more obvious and less error-prone. Patch by James Clarke Differential Revision: http://reviews.llvm.org/D54207 llvm-svn: 346893
* [ELF] Refactor per-target TLS layout configuration. NFC.Ryan Prichard2018-10-311-2/+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
* [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-4/+4
| | | | | | | | | | 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
* [ELF] Add support for Armv5 and Armv6 compatible ThunksPeter Smith2018-08-201-31/+35
| | | | | | | | | | | | | | | | 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] Add support for older Arm Architectures with smaller branch rangePeter Smith2018-08-201-3/+24
| | | | | | | | | | | | | | The Thumb BL and BLX instructions on older Arm Architectures such as v5 and v6 have a constrained encoding J1 and J2 must equal 1, later Architectures relaxed this restriction allowing J1 and J2 to be used to calculate a larger immediate. This patch adds support for the old encoding, it is used when the build attributes for the input objects only contain older architectures. Differential Revision: https://reviews.llvm.org/D50076 llvm-svn: 340159
* [ELF][ARM] Implement support for Tag_ABI_VFP_argsPeter Smith2018-07-311-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Tag_ABI_VFP_args build attribute controls the procedure call standard used for floating point parameters on ARM. The values are: 0 - Base AAPCS (FP Parameters passed in Core (Integer) registers 1 - VFP AAPCS (FP Parameters passed in FP registers) 2 - Toolchain specific (Neither Base or VFP) 3 - Compatible with all (No use of floating point parameters) If the Tag_ABI_VFP_args build attribute is missing it has an implicit value of 0. We use the attribute in two ways: - Detect a clash in calling convention between Base, VFP and Toolchain. we follow ld.bfd's lead and do not error if there is a clash between an implicit Base AAPCS caused by a missing attribute. Many projects including the hard-float (VFP AAPCS) version of glibc contain assembler files that do not use floating point but do not have Tag_ABI_VFP_args. - Set the EF_ARM_ABI_FLOAT_SOFT or EF_ARM_ABI_FLOAT_HARD ELF header flag for Base or VFP AAPCS respectively. This flag is used by some ELF loaders. References: - Addenda to, and Errata in, the ABI for the ARM Architecture for Tag_ABI_VFP_args - Elf for the ARM Architecture for ELF header flags Fixes PR36009 Differential Revision: https://reviews.llvm.org/D49993 llvm-svn: 338377
* [ELF] - Eliminate Target::isPicRel method.George Rimar2018-04-051-11/+2
| | | | | | | | | | | | | | | | | | | | | | 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-8/+8
| | | | | | | | Template is just unnecessary. Differential Revision: https://reviews.llvm.org/D45063 llvm-svn: 328843
* [ELF] Recommit 327248 with Arm using the .got for _GLOBAL_OFFSET_TABLE_Peter Smith2018-03-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | This is the same as 327248 except Arm defining _GLOBAL_OFFSET_TABLE_ to be the base of the .got section as some existing code is relying upon it. For most Targets the _GLOBAL_OFFSET_TABLE_ symbol is expected to be at the start of the .got.plt section so that _GLOBAL_OFFSET_TABLE_[0] = reserved value that is by convention the address of the dynamic section. Previously we had defined _GLOBAL_OFFSET_TABLE_ as either the start or end of the .got section with the intention that the .got.plt section would follow the .got. However this does not always hold with the current default section ordering so _GLOBAL_OFFSET_TABLE_[0] may not be consistent with the reserved first entry of the .got.plt. X86, X86_64 and AArch64 will use the .got.plt. Arm, Mips and Power use .got Fixes PR36555 Differential Revision: https://reviews.llvm.org/D44259 llvm-svn: 327823
* Use references instead of pointers. NFC.Rafael Espindola2017-12-191-6/+4
| | | | | | | These values are trivially never null. While at it, also use InputSection instead of InputSectionBase when possible. llvm-svn: 321126
* [ELF] Fix typo in comment. NFCShoaib Meenai2017-12-181-1/+1
| | | | llvm-svn: 321022
* [ELF] Optimize Arm PLT sequencesPeter Smith2017-12-181-9/+70
| | | | | | | | | | | | | | A more efficient PLT sequence can be used when the distance between the .plt and the end of the .plt.got is less than 128 Megabytes, which is frequently true. We fall back to the old sequence when the offset is larger than 128 Megabytes. This gives us an alternative to forcing the longer entries with --long-plt as we gracefully fall back to it as needed. See ELF for the ARM Architecture Appendix A for details of the PLT sequence. Differential Revision: https://reviews.llvm.org/D41246 llvm-svn: 320987
* [ELF][ARM] Refine check for when undefined weak needs a ThunkPeter Smith2017-11-271-4/+3
| | | | | | | | | | | | | | | | When an undefined weak reference has a PLT entry we must generate a range extension thunk for any B or BL that can't reach the PLT entry. This change explicitly looks for whether a PLT entry exists rather than assuming that weak references never need PLT entries unless Config->Shared is in operation. This covers the case where we are linking an executable with dynamic linking, hence a PLT entry will be needed for undefined weak references. This case comes up in real programs over 32 Mb in size as there is a B to a weak reference __gmon__start__ in the Arm crti.o for glibc. Differential Revision: https://reviews.llvm.org/D40248 llvm-svn: 319020
* Rename SymbolBody -> SymbolRui Ueyama2017-11-031-8/+8
| | | | | | | | | | | | | 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
* [ELF] Introduce range extension thunks for ARMPeter Smith2017-10-271-4/+12
| | | | | | | | | | | | | | This change adds initial support for range extension thunks. All thunks must be created within the first pass so some corner cases are not supported. A follow up patch will add support for multiple passes. With this change the existing tests arm-branch-error.s and arm-thumb-branch-error.s now no longer fail with an out of range branch. These have been renamed and tests added for the range extension thunk. Differential Revision: https://reviews.llvm.org/D34691 llvm-svn: 316752
* [ELF] Pre-create ThunkSections at Target specific intervalsPeter Smith2017-10-271-0/+31
| | | | | | | | | | | | | | When an OutputSection is larger than the branch range for a Target we need to place thunks such that they are always in range of their caller, and sufficiently spaced to maximise the number of callers that can use the thunk. We use the simple heuristic of placing the ThunkSection at intervals corresponding to a target specific branch range. If the OutputSection is small we put the thunks at the end of the executable sections. Differential Revision: https://reviews.llvm.org/D34689 llvm-svn: 316751
* [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
* LLD/ELF: Allow targets to set e_flagsKonstantin Zhuravlyov2017-10-241-0/+8
| | | | | | Differential Revision: https://reviews.llvm.org/D39139 llvm-svn: 316460
* 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-17/+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
* Add a helper for checking for weak undef. NFC.Rafael Espindola2017-09-131-2/+1
| | | | llvm-svn: 313188
* 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
* [ELF] Introduce target specific inBranchRange() functionPeter Smith2017-07-171-0/+45
| | | | | | | | | | | | | | In preparation for range extension thunks introduce a function that will check whether a branch identified by a relocation type at a source address can reach a destination. For targets where range extension thunks are not supported the function will return true as it is not expected that branches are out of range. An implementation has been provided for ARM. Differential Revision: https://reviews.llvm.org/D34690 llvm-svn: 308188
* Add trap instructions for ARM and MIPS.Rui Ueyama2017-06-261-0/+1
| | | | | | | This patch fills holes in executable sections with 0xd4 (ARM) or 0xef (MIPS). These trap instructions were suggested by Theo de Raadt. llvm-svn: 306322
* 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/+432
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