summaryrefslogtreecommitdiffstats
path: root/lld/ELF/Target.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [ELF] Avoid false-positive assert in getErrPlace()Alex Richardson2020-01-171-1/+1
| | | | | | | | | | | | | This assertion was added as part of D70659 but did not account for .bss input sections. I noticed that this assert was incorrectly triggering while building FreeBSD for MIPS64. Fixed by relaxing the assert to also account for SHT_NOBITS input sections and adjust the test mips-jalr-non-function.s to link a file with a .bss section first. Reviewed By: MaskRay, grimar Differential Revision: https://reviews.llvm.org/D72567 (cherry picked from commit 441410be471d5d0a5d1d47cf363de155e397a0c2)
* [ELF] Make TargetInfo::writeIgotPlt a no-opFangrui Song2020-01-101-4/+0
| | | | | | | | | | | | | | RELA targets don't read initial .got.plt entries. REL targets (ARM, x86-32) write the address of the IFUNC resolver to the entry (`write32le(buf, s.getVA())`). The default writeIgotPlt() is not meaningful. Make it a no-op. AArch64 and x86-64 will have 0 as initial .got.plt entries associated with IFUNC. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D72474
* Re-apply "[ELF] Allow getErrPlace() to work before Out::bufferStart is set"Alex Richardson2020-01-091-4/+10
| | | | | | This time with a fix for the UBSAN failure. Differential Revision: https://reviews.llvm.org/D70659
* Revert "[ELF] Allow getErrPlace() to work before Out::bufferStart is set"Vlad Tsyrklevich2019-12-131-4/+4
| | | | | | This reverts commit 2bbd32f5e8f0f62d895966e2623d9bdb9778b50b, it was causing UBSan failures like the following: lld/ELF/Target.cpp:103:41: runtime error: applying non-zero offset 24 to null pointer
* [ELF] Allow getErrPlace() to work before Out::bufferStart is setAlex Richardson2019-12-131-4/+4
| | | | | | | | | | | | | | | | | | Summary: So far it seems like the only test affected by this change is the one I recently added for R_MIPS_JALR relocations since the other test cases that use this function early (unknown-relocation-*) do not have a valid input section for the relocation offset. Reviewers: ruiu, grimar, MaskRay, espindola Reviewed By: ruiu, MaskRay Subscribers: emaste, sdardis, jrtc27, atanasyan, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70659
* [ELF][AArch64] Support R_AARCH64_{CALL26,JUMP26} range extension thunks with ↵Fangrui Song2019-12-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Make nullptr check more robustRui Ueyama2019-10-101-6/+4
| | | | | | | | | | | | The only condition that isecLoc becomes null is Out::bufferStart == nullptr, isec->getParent()->offset == 0, and isec->outSecOff == 0. We can check the first condition only once. llvm-svn: 374332
* [lld] getErrPlace(): don't perform arithmetics on maybe-null pointerRoman Lebedev2019-10-101-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | isecLoc there can be null, but at the same time isec->getSize() may be non-null. It is UB to offset a nullptr.The most straight-forward fix here appears to perform casts+normal integral arithmetics. FAIL: lld :: ELF/invalid/invalid-relocation-aarch64.test (1158 of 2217) ******************** TEST 'lld :: ELF/invalid/invalid-relocation-aarch64.test' FAILED ******************** Script: -- : 'RUN: at line 2'; /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/yaml2obj /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-aarch64.test -o /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-aarch64.test.tmp.o : 'RUN: at line 3'; not /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/ld.lld /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-aarch64.test.tmp.o -o /dev/null 2>&1 | /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/FileCheck /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-aarch64.test -- Exit Code: 1 Command Output (stderr): -- /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-aarch64.test:4:10: error: CHECK: expected string not found in input # CHECK: error: unknown relocation (1024) against symbol foo ^ <stdin>:1:1: note: scanning from here /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/ELF/Target.cpp:100:41: runtime error: applying non-zero offset 24 to null pointer ^ <stdin>:1:118: note: possible intended match here /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/ELF/Target.cpp:100:41: runtime error: applying non-zero offset 24 to null pointer ^ -- ******************** Testing: 0.. 10.. 20.. 30.. 40.. 50. FAIL: lld :: ELF/invalid/invalid-relocation-x64.test (1270 of 2217) ******************** TEST 'lld :: ELF/invalid/invalid-relocation-x64.test' FAILED ******************** Script: -- : 'RUN: at line 2'; /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/yaml2obj /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-x64.test -o /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp1.o : 'RUN: at line 3'; echo ".global foo; foo:" > /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp2.s : 'RUN: at line 4'; /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/llvm-mc /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp2.s -o /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp2.o -filetype=obj -triple x86_64-pc-linux : 'RUN: at line 5'; not /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/ld.lld /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp1.o /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp2.o -o /dev/null 2>&1 | /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/FileCheck /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-x64.test -- Exit Code: 1 Command Output (stderr): -- /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-x64.test:6:10: error: CHECK: expected string not found in input # CHECK: error: unknown relocation (152) against symbol foo ^ <stdin>:1:1: note: scanning from here /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/ELF/Target.cpp:100:41: runtime error: applying non-zero offset 24 to null pointer ^ <stdin>:1:118: note: possible intended match here /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/ELF/Target.cpp:100:41: runtime error: applying non-zero offset 24 to null pointer ^ -- ******************** Testing: 0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. Testing Time: 20.73s ******************** Failing Tests (2): lld :: ELF/invalid/invalid-relocation-aarch64.test lld :: ELF/invalid/invalid-relocation-x64.test llvm-svn: 374329
* [ELF] Wrap things in `namespace lld { namespace elf {`, NFCFangrui Song2019-10-071-7/+10
| | | | | | | | | | | 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
* [Coding style change] Rename variables so that they start with a lowercase ↵Rui Ueyama2019-07-101-45/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [PPC64] toc-indirect to toc-relative relaxationFangrui Song2019-05-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* De-template X86_64TargetInfo. NFC.Rui Ueyama2019-03-281-2/+0
| | | | llvm-svn: 357191
* Make TargetInfo const. NFC.Rui Ueyama2019-03-281-2/+2
| | | | | | | We do not mutate a TargetInfo instance after creating it. This change makes it explicit. llvm-svn: 357185
* ELF: Write .eh_frame_hdr explicitly after writing .eh_frame.Peter Collingbourne2019-02-281-1/+1
| | | | | | | | | | | This lets us remove the special case from Writer::writeSections(), and also fixes a bug where .eh_frame_hdr isn't necessarily written in the correct order if a linker script moves .eh_frame and .eh_frame_hdr into the same output section. Differential Revision: https://reviews.llvm.org/D58795 llvm-svn: 355153
* 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
* [LLD][ELF] - Support MSP430.George Rimar2019-01-101-0/+2
| | | | | | | | | | | Patch by Michael Skvortsov! This change adds a basic support for linking static MSP430 ELF code. Implemented relocation types are intended to correspond to the BFD. Differential revision: https://reviews.llvm.org/D56535 llvm-svn: 350819
* Use llvm_unreachable for unreachable code.Rui Ueyama2018-11-011-2/+2
| | | | llvm-svn: 345885
* Reland "[PPC64] Add split - stack support."Sean Fertile2018-10-161-3/+2
| | | | | | | | | | | | | | Recommitting https://reviews.llvm.org/rL344544 after fixing undefined behavior from left-shifting a negative value. Original commit message: This support is slightly different then the X86_64 implementation in that calls to __morestack don't need to get rewritten to calls to __moresatck_non_split when a split-stack caller calls a non-split-stack callee. Instead the size of the stack frame requested by the caller is adjusted prior to the call to __morestack. The size the stack-frame will be adjusted by is tune-able through a new --split-stack-adjust-size option. llvm-svn: 344622
* Revert "[PPC64] Add split - stack support."Sean Fertile2018-10-151-2/+3
| | | | | | | | This reverts commit https://reviews.llvm.org/rL344544, which causes failures on a undefined behaviour sanitizer bot --> lld/ELF/Arch/PPC64.cpp:849:35: runtime error: left shift of negative value -1 llvm-svn: 344551
* [PPC64] Add split - stack support.Sean Fertile2018-10-151-3/+2
| | | | | | | | | | | | | This support is slightly different then the X86_64 implementation in that calls to __morestack don't need to get rewritten to calls to __moresatck_non_split when a split-stack caller calls a non-split-stack callee. Instead the size of the stack frame requested by the caller is adjusted prior to the call to __morestack. The size the stack-frame will be adjusted by is tune-able through a new --split-stack-adjust-size option. Differential Revision: https://reviews.llvm.org/D52099 llvm-svn: 344544
* Support RISC-VRui Ueyama2018-08-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch by PkmX. This patch makes lld recognize RISC-V target and implements basic relocation for RV32/RV64 (and RVC). This should be necessary for static linking ELF applications. The ABI documentation for RISC-V can be found at: https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md. Note that the documentation is far from complete so we had to figure out some details from bfd. The patch should be pretty straightforward. Some highlights: - A new relocation Expr R_RISCV_PC_INDIRECT is added. This is needed as the low part of a PC-relative relocation is linked to the corresponding high part (auipc), see: https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md#pc-relative-symbol-addresses - LLVM's MC support for RISC-V is very incomplete (we are working on this), so tests are given in objectyaml format with the original assembly included in the comments. Once we have complete support for RISC-V in MC, we can switch to llvm-as/llvm-objdump. - We don't support linker relaxation for now as it requires greater changes to lld that is beyond the scope of this patch. Once this is accepted we can start to work on adding relaxation to lld. Differential Revision: https://reviews.llvm.org/D39322 llvm-svn: 339364
* Implement framework for linking split-stack object files, and x86_64 support.Sterling Augustine2018-07-171-0/+6
| | | | llvm-svn: 337332
* [ELF] - Cleanup error reporting code and cover with the test. NFC.George Rimar2018-07-021-2/+2
| | | | | | | | | | | | | | | | We have the following code that is uncovered with the test: https://github.com/llvm-mirror/lld/blob/master/ELF/Target.cpp#L95 This patch: 1) Removes "!IS" check. Because at that point of execution (we are reolving the relocations during writing output) we should only have InputSection type of the sections in the vector. (because we already converted MergeInputSection in mergeSections() and combined EhInputSections in combineEhFrameSections()). 2) Covers the "!IS->getParent()" with the test. llvm-svn: 336106
* Add Hexagon SupportSid Manning2018-06-131-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D47791 llvm-svn: 334637
* [ELF] - Teach LLD to hint about -fdebug-types-section.George Rimar2018-03-211-8/+8
| | | | | | | | | Patch teaches LLD to hint user about -fdebug-types-section flag if relocation overflow happens in debug section. Differential revision: https://reviews.llvm.org/D40954 llvm-svn: 328081
* Use dyn_cast instead of dyn_cast_or_null.Rafael Espindola2017-12-201-1/+1
| | | | | | There should be no null sections in InputSections. llvm-svn: 321219
* Rename SymbolBody -> SymbolRui Ueyama2017-11-031-2/+2
| | | | | | | | | | | | | 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-1/+1
| | | | | | | | | | | | | | 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
* [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
* Define RelType to represent relocation types.Rui Ueyama2017-10-111-12/+11
| | | | | | | | | | | | | | | | | | 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
* [ELF] Set Dot initially to --image-base value when using linker scriptsJames Henderson2017-10-101-0/+7
| | | | | | | | | | | | | | | | | | | | | When parsing linker scripts, LLD previously started with a '.' value of 0, regardless of the internal default image base for the target, and regardless of switches such as --image-base. It seems reasonable to use a different image base value when using linker scripts and --image-base is specified, since otherwise the switch has no effect. This change does this, as well as removing unnecessary initialisation of Dot where it is not used. The default image base should not be used when processing linker scripts, because this will change the behaviour for existing linker script users, and potentially result in invalid output being produced, as a subsequent assignment to Dot could move the location counter backwards. Instead, we maintain the existing behaviour of starting from 0 if --image-base is not specified. Reviewers: ruiu Differential Revision: https://reviews.llvm.org/D38360 llvm-svn: 315293
* [ELF] Introduce target specific inBranchRange() functionPeter Smith2017-07-171-0/+5
| | | | | | | | | | | | | | 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 basic 64-bit SPARC supportRui Ueyama2017-06-281-0/+2
| | | | | | | | | | | | | | | Add support for the most common SPARC relocations. Make DT_PLTGOT point to the PLT on SPARC. Mark the PLT as executable on SPARC. This adds a basic test that creates a SPARV9 executable that invokes the exit system call on OpenBSD. Patch by Mark Kettenis. Differential Revision: https://reviews.llvm.org/D34618 llvm-svn: 306565
* Do not use make<> to allocate TargetInfo. NFC.Rui Ueyama2017-06-161-14/+14
| | | | llvm-svn: 305577
* Split Target.cpp into small files.Rui Ueyama2017-06-161-2337/+42
| | | | | | | | | | | | 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
* [ELF] Initial migration of AVR targetLeslie Zhai2017-06-151-0/+35
| | | | | | | | | | Reviewers: ruiu, rafael, grimar, atanasyan, psmith, dylanmckay Reviewed By: ruiu, rafael, grimar, dylanmckay Differential Revision: https://reviews.llvm.org/D32991 llvm-svn: 305444
* Relax the overflow checking of R_386_PC16.Rafael Espindola2017-06-101-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the freebsd early boot code fails to link. The issue reduces to 16 bit code at position 0x7000 wanting to jump to position 0x9000. That is represented in the .o file as a relocation with no symbol and an addend of 0x9000 - 2 (The -2 is because i386 uses the ip after the current instruction for jumps). If the addend is interpreted as signed (it should), it is -28674. In a 32 bit architecture, that is the address 0xffff8ffe. To get there from 0x7000 we have to add 4294909950 (too big) or subtract 57346 (too small). We then produce an error. What lld is missing is the fact that at runtime this will actually be a 16 bit architecture and adding 0x1ffe produces 0x8ffe which is the correct result in 16 bits (-28674). Since we have a 16 bit addend and a 16 bit PC, the relocation can move the PC to any 16 bit address and that is the only thing we really need to check: if the address we are pointing to fits in 16 bits. This is unfortunately hard to do since we have to delay subtracting the PC and if we want to do that outside of Target.cpp, we have to move the overflow check out too. An incomplete patch that tries to do that is at https://reviews.llvm.org/D34070 This patch instead just relaxes the check. Since the value we have is the destination minus the PC and the PC is 16 bits, it should fit in 17 bits if the destination fits in 16 too. bfd had a similar issue for some time and got a similar fix: https://sourceware.org/ml/binutils/2005-08/msg00001.html llvm-svn: 305135
* Use LLVM_FALLTHROUGH.Rui Ueyama2017-06-081-3/+3
| | | | llvm-svn: 305010
* Move Object format code to lib/BinaryFormat.Zachary Turner2017-06-071-1/+1
| | | | | | | | | | | | This creates a new library called BinaryFormat that has all of the headers from llvm/Support containing structure and layout definitions for various types of binary formats like dwarf, coff, elf, etc as well as the code for identifying a file from its magic. Differential Revision: https://reviews.llvm.org/D33843 llvm-svn: 304864
* Store a single Parent pointer for InputSectionBase.Rafael Espindola2017-05-311-2/+2
| | | | | | | | | | | | | | | Before InputSectionBase had an OutputSection pointer, but that was not always valid. For example, if it was a merge section one actually had to look at MergeSec->OutSec. This was brittle and caused bugs like the one fixed by r304260. We now have a single Parent pointer that points to an OutputSection for InputSection, but to a SyntheticSection for merge sections and .eh_frame. This makes it impossible to accidentally access an invalid OutSec. llvm-svn: 304338
* [ELF] Support R_ARM_SBREL32 RelocationPeter Smith2017-05-181-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | This change adds support for the R_ARM_SBREL32 relocation. The relocation is a base relative relocation that is produced by clang/llvm when -frwpi is used. The use case for the -frwpi option is position independent data for embedded systems that do not have a GOT. With -frwpi all data is accessed via an offset from a base register (usually r9), where r9 is set at run time to where the data has been loaded. The base of the data is known as the static base. The ARM ABI defines the static base as: B(S) is the addressing origin of the output segment defining the symbol S. The origin is not required to be the base address of the segment. For simplicity we choose to use the base address of the segment. The ARM procedure call standard only defines a read write variant using R_ARM_SBREL32 relocations. The read-only data is accessed via pc-relative offsets from the code, this is implemented in clang as -fropi. Fixes PR32924 Differential Revision: https://reviews.llvm.org/D33280 llvm-svn: 303337
* [ELF] - Detemplate elf::addSyntheticLocal(). NFC.George Rimar2017-05-161-4/+4
| | | | llvm-svn: 303155
* [ELF] - Stop support of DF_STATIC_TLS flag.George Rimar2017-05-121-9/+0
| | | | | | | | This reverts changes introduced in r302414 "[ELF] - Set DF_STATIC_TLS flag for i386 target." Because DF_STATIC_TLS does not look to be used by glibc or anything else. llvm-svn: 302884
* [ELF] - Don't allow R_X86_64_TPOFF32 dynamic relocation when linking PICGeorge Rimar2017-05-121-1/+2
| | | | | | | | | | | | | | Both gold and bfd restrict that one: ld.bfd: test.o: relocation R_X86_64_TPOFF32 against `var' can not be used when making a shared object; recompile with -fPIC ld.gold: error: test.o: unsupported reloc 23 against global symbol var What looks reasonable because it is 32 bit one. Patch do the same. Differential revision: https://reviews.llvm.org/D33100 llvm-svn: 302881
* Detemplate the got.Rafael Espindola2017-05-111-3/+3
| | | | | | This is a bit hackish, but allows for a lot of followup cleanups. llvm-svn: 302845
* Reduce templating. NFC.Rafael Espindola2017-05-111-2/+2
| | | | llvm-svn: 302843
* Reduce template usage. NFC.Rafael Espindola2017-05-111-10/+10
| | | | llvm-svn: 302832
* Reduce template usage. NFC.Rafael Espindola2017-05-111-2/+2
| | | | llvm-svn: 302826
* [ELF] - Use LLVM_FALLTHROUGH in code.George Rimar2017-05-101-2/+4
| | | | | | | | | | | | When compiling LLD using GCC 7 it reports warnings like: "warning: this statement may fall through [-Wimplicit-fallthrough=]" LLVM has LLVM_FALLTHROUGH macro which can be used to avoid such warnings. Together with D33036 this patch fixes them. Differential revision: https://reviews.llvm.org/D32907 llvm-svn: 302666
* [ELF] - Set DF_STATIC_TLS flag for i386 target.George Rimar2017-05-081-0/+9
| | | | | | | | | | | | | | | | | | This is PR32437. DF_STATIC_TLS If set in a shared object or executable, this flag instructs the dynamic linker to reject attempts to load this file dynamically. It indicates that the shared object or executable contains code using a static thread-local storage scheme. Implementations need not support any form of thread-local storage. Patch checks if IE/LE relocations were used to check if code uses static model. If so it sets the DF_STATIC_TLS flag. Differential revision: https://reviews.llvm.org/D32354 llvm-svn: 302414
OpenPOWER on IntegriCloud