summaryrefslogtreecommitdiffstats
path: root/lld/ELF/Arch/Mips.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [ELF] writePlt, writeIplt: replace parameters gotPltEntryAddr and index with ↵Fangrui Song2019-12-181-4/+5
| | | | | | | | | | `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] Delete relOff from TargetInfo::writePLTFangrui Song2019-12-161-3/+2
| | | | | | | | | | | | | | 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/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | addends Fixes AArch64 part of PR40438 The current range extension thunk framework does not handle a relocation relative to a STT_SECTION symbol with a non-zero addend, which may be used by jumps/calls to local functions on some RELA targets (AArch64, powerpc ELFv1, powerpc64 ELFv2, etc). See PR40438 and the following code for examples: // clang -target $target a.cc // .text.cold may be placed in a separate output section. // The distance between bar in .text.cold and foo in .text may be larger than 128MiB. static void foo() {} __attribute__((section(".text.cold"))) static int bar() { foo(); return 0; } __attribute__((used)) static int dummy = bar(); This patch makes such thunks with addends work for AArch64. The target independent part can be reused by PPC in the future. On REL targets (ARM, MIPS), jumps/calls are not represented as STT_SECTION + non-zero addend (see MCELFObjectTargetWriter::needsRelocateWithSymbol), so they don't need this feature, but we need to make sure this patch does not affect them. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D70637
* Ignore R_MIPS_JALR relocations against non-function symbolsAlex Richardson2019-11-201-0/+11
| | | | | | | | | | | | | | | | | | | | Summary: Current versions of clang would erroneously emit this relocation not only against functions (loaded from the GOT) but also against data symbols (e.g. a table of function pointers). LLD was then changing this into a branch-and-link instruction, causing the program to jump to the data symbol at run time. I discovered this problem when attempting to boot MIPS64 FreeBSD after updating the to the latest upstream master. Reviewers: atanasyan, jrtc27, espindola Reviewed By: atanasyan Subscribers: emaste, sdardis, krytarowski, MaskRay, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70406
* [ELF][MIPS] De-template writeValue. NFCFangrui Song2019-10-071-23/+20
| | | | | | Depends on D68561. llvm-svn: 373886
* [ELF] Wrap things in `namespace lld { namespace elf {`, NFCFangrui Song2019-10-071-12/+15
| | | | | | | | | | | This makes it clear `ELF/**/*.cpp` files define things in the `lld::elf` namespace and simplifies `elf::foo` to `foo`. Reviewed By: atanasyan, grimar, ruiu Differential Revision: https://reviews.llvm.org/D68323 llvm-svn: 373885
* [ELF][MIPS] Use lld::elf::{read,write}* instead of ↵Fangrui Song2019-10-071-70/+68
| | | | | | | | | | | | | | llvm::support::endian::{read,write}* This allows us to delete `using namespace llvm::support::endian` and simplify D68323. This change adds runtime config->endianness check but the overhead should be negligible. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D68561 llvm-svn: 373884
* [mips] Relax jalr/jr instructions using R_MIPS_JALR relocationSimon Atanasyan2019-09-261-1/+21
| | | | | | | | | | | The R_MIPS_JALR relocation denotes jalr/jr instructions in position independent code. Both these instructions take a target's address from the $25 register. If offset to the target symbol fits into the 18-bits, it's more efficient to replace jalr/jr by bal/b instructions. Differential Revision: https://reviews.llvm.org/D68057 llvm-svn: 372951
* [mips] Assign R_TLS type to the R_MIPS_TLS_TPREL_XXX relocations. NFCSimon Atanasyan2019-07-241-8/+4
| | | | | | | | That allows to remove duplicated code which subtracts 0x7000 from the R_MIPS_TLS_TPREL_XXX relocations values in the `MIPS::relocateOne` function. llvm-svn: 366888
* [Coding style change] Rename variables so that they start with a lowercase ↵Rui Ueyama2019-07-101-297/+297
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [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
* ELF: De-template ELFFileBase. NFCI.Peter Collingbourne2019-04-051-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D60304 llvm-svn: 357806
* [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-141-2/+4
| | | | | | | | | | | | 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
* 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][MIPS] Use MIPS R6 `sigrie` as a trap instructionSimon Atanasyan2018-11-161-1/+3
| | | | | | | | | | | | | | | Current value using as a trap instruction (0xefefefef) is not a good choice for MIPS because it's a valid MIPS instruction `swc3 $15,-4113(ra)`. This patch replaces 0xefefefef by 0x04170001. For all MIPS ISA revisions before R6, this value is just invalid instruction. Starting from MIPS R6 it's a valid instruction `sigrie 1` which signals a Reserved Instruction exception. mips-traps.s test case is added to test trap encoding. Other test cases are modified to remove redundant checking. Differential revision: https://reviews.llvm.org/D54154 llvm-svn: 347029
* [ELF] Make TrapInstr and Filler byte arrays. NFC.Simon Atanasyan2018-11-141-1/+1
| | | | | | | | | | | | 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] - 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][MIPS] Remove support for linking microMIPS 64-bit codeSimon Atanasyan2018-07-061-19/+1
| | | | | | | | | Remove support for linking microMIPS 64-bit code because this kind of ISA is rarely used and unsupported by LLVM. Differential revision: https://reviews.llvm.org/D48949 llvm-svn: 336413
* [ELF][MIPS] Reorganize isMipsPIC routine. NFCSimon Atanasyan2018-05-041-7/+10
| | | | llvm-svn: 331555
* [ELF][MIPS] Check that a section has a valid reference to a file in the ↵Simon Atanasyan2018-05-031-1/+5
| | | | | | isMipsPIC routine llvm-svn: 331470
* [ELF] - Eliminate Target::isPicRel method.George Rimar2018-04-051-6/+3
| | | | | | | | | | | | | | | | | | | | | | 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-21/+21
| | | | | | | | 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
* Revert r327248, "For most Targets the _GLOBAL_OFFSET_TABLE_ symbol is ↵Peter Collingbourne2018-03-161-1/+0
| | | | | | | | | | | expected to be at" This change broke ARM code that expects to be able to add _GLOBAL_OFFSET_TABLE_ to the result of an R_ARM_REL32. I will provide a reproducer on llvm-commits. llvm-svn: 327688
* For most Targets the _GLOBAL_OFFSET_TABLE_ symbol is expected to be atPeter Smith2018-03-111-0/+1
| | | | | | | | | | | | | | | | | | 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, Arm and AArch64 will use the .got.plt. Mips and Power use .got Fixes PR36555 Differential Revision: https://reviews.llvm.org/D44259 llvm-svn: 327248
* [mips][lld] Address post commit review nit.Simon Dardis2018-02-211-3/+2
| | | | | | | Address @ruiu's post commit review comment about a value which is intended to be a unsigned 32 bit integer as using uint32_t rather than unsigned. llvm-svn: 325713
* [mips][lld] Spectre variant two mitigation for MIPSR2Simon Dardis2018-02-201-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch provides migitation for CVE-2017-5715, Spectre variant two, which affects the P5600 and P6600. It implements the LLD part of -z hazardplt. Like the Clang part of this patch, I have opted for that specific option name in case alternative migitation methods are required in the future. The mitigation strategy suggested by MIPS for these processors is to use hazard barrier instructions. 'jalr.hb' and 'jr.hb' are hazard barrier variants of the 'jalr' and 'jr' instructions respectively. These instructions impede the execution of instruction stream until architecturally defined hazards (changes to the instruction stream, privileged registers which may affect execution) are cleared. These instructions in MIPS' designs are not speculated past. These instructions are defined by the MIPS32R2 ISA, so this mitigation method is not compatible with processors which implement an earlier revision of the MIPS ISA. For LLD, this changes PLT stubs to use 'jalr.hb' and 'jr.hb'. Reviewers: atanasyan, ruiu Differential Revision: https://reviews.llvm.org/D43488 llvm-svn: 325647
* [ELF][MIPS] Rename function to be consistent with other names. NFCSimon Atanasyan2018-01-291-16/+16
| | | | llvm-svn: 323650
* [ELF][MIPS] Rename function. NFCSimon Atanasyan2018-01-181-21/+21
| | | | llvm-svn: 322861
* [ELF][MIPS] Decompose relocation type for N32 / N64 earlier. NFCSimon Atanasyan2018-01-181-3/+3
| | | | | | | | We need to decompose relocation type for N32 / N64 ABI. Let's do it before any other manipulations with relocation type in the `relocateOne` routine. llvm-svn: 322860
* [MIPS] Write PLT0 entry in case of linking N64 ABI codeSimon Atanasyan2017-11-221-2/+11
| | | | llvm-svn: 318831
* [MIPS] Set STO_MIPS_MICROMIPS flag and less-significant bit for microMIPS ↵Simon Atanasyan2017-11-131-2/+0
| | | | | | | | | | | | symbols microMIPS symbols including microMIPS PLT records created for regular symbols needs to be marked by STO_MIPS_MICROMIPS flag in a symbol table. Additionally microMIPS entries in a dynamic symbol table should have configured less-significant bit. That allows to escape teaching a dynamic linker about microMIPS symbols. llvm-svn: 318097
* [MIPS] Setup less-significant bit in the .got and .got.plt entries in case ↵Simon Atanasyan2017-11-081-3/+6
| | | | | | | | | of microMIPS code The less-significant bit signals about microMIPS code for jump/branch instructions. llvm-svn: 317741
* Move MIPS-specific code from Symbols.cpp to MIPS.cpp.Rui Ueyama2017-11-071-1/+18
| | | | | | | | | We have a lot of "if (MIPS)" conditions in lld because the MIPS' ABI is different at various places than other arch's ABIs at where it don't have to be different, but we at least want to reduce MIPS-ness from the regular classes. llvm-svn: 317525
* ELF: Merge DefinedRegular and Defined.Peter Collingbourne2017-11-061-1/+1
| | | | | | | | | Now that DefinedRegular is the only remaining derived class of Defined, we can merge the two classes. Differential Revision: https://reviews.llvm.org/D39667 llvm-svn: 317448
* Rename SymbolBody -> SymbolRui Ueyama2017-11-031-6/+6
| | | | | | | | | | | | | 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-2/+2
| | | | | | | | | | | | | | 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
* Remove an unnecessary inheritance.Rui Ueyama2017-10-261-2/+2
| | | | llvm-svn: 316716
* [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-1/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D39139 llvm-svn: 316460
* Remove one parameter from Target::getRelExpr.Rui Ueyama2017-10-121-12/+14
| | | | | | | | 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-18/+17
| | | | | | | | | | | | | | | | | | 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][MIPS] Check for overflow when writing R_MIPS_CALL16 and ↵Alexander Richardson2017-10-061-2/+2
| | | | | | | | | | | | | | | | | | | | R_MIPS_TLS_GOTTPREL Summary: These are 16 bit relocations and not part of a HI/LO pair so we need to check that they don't overflow. Reviewers: atanasyan Reviewed By: atanasyan Subscribers: ruiu, llvm-commits, emaste, sdardis Tags: #lld Differential Revision: https://reviews.llvm.org/D38614 llvm-svn: 315073
* [MIPS] Generate thunks for microMIPS codeSimon Atanasyan2017-10-031-5/+0
| | | | | | | | If symbol has the STO_MIPS_MICROMIPS flag and requires a thunk to perform call PIC from non-PIC functions, we need to generate a thunk with microMIPS code. llvm-svn: 314797
OpenPOWER on IntegriCloud