summaryrefslogtreecommitdiffstats
path: root/lld/ELF/Thunks.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [ELF][PPC32] Support range extension thunks with addendsFangrui Song2020-01-251-4/+41
| | | | | | | | | | | * Generalize the code added in D70637 and D70937. We should eventually remove the EM_MIPS special case. * Handle R_PPC_LOCAL24PC the same way as R_PPC_REL24. Reviewed By: Bdragon28 Differential Revision: https://reviews.llvm.org/D73424 (cherry picked from commit 70389be7a029bec3c45991a60b627445ef996120)
* [ELF][PPC64] Improve "call lacks nop" diagnostic and make it compatible with ↵Fangrui Song2019-12-291-0/+1
| | | | | | | | | | | | | | | | GCC<5.5 and GCC<6.4 GCC before r245813 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79439) did not emit nop after b/bl. This can happen with recursive calls. r245813 was back ported to GCC 5.5 and GCC 6.4. This is common, for example, libstdc++.a(locale.o) shipped with GCC 4.9 and many objects in netlib lapack can cause lld to error. gold allows such calls to the same section. Our __plt_foo symbol's `section` field is used for ThunkSection, so we can't implement a similar loosen rule easily. But we can make use of its `file` field which is currently NULL. Differential Revision: https://reviews.llvm.org/D71639
* [ELF][PPC32] Implement IPLT code sequence for non-preemptible IFUNCFangrui Song2019-12-291-9/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Similar to D71509 (EM_PPC64), on EM_PPC, the IPLT code sequence should be similar to a PLT call stub. Unlike EM_PPC64, EM_PPC -msecure-plt has small/large PIC model differences. * -fpic/-fpie: R_PPC_PLTREL24 r_addend=0. The call stub loads an address relative to `_GLOBAL_OFFSET_TABLE_`. * -fPIC/-fPIE: R_PPC_PLTREL24 r_addend=0x8000. (A partial linked object file may have an addend larger than 0x8000.) The call stub loads an address relative to .got2+0x8000. Just assume large PIC model for now. This patch makes: // clang -fuse-ld=lld -msecure-plt -fno-pie -no-pie a.c // clang -fuse-ld=lld -msecure-plt -fPIE -pie a.c #include <stdio.h> static void impl(void) { puts("meow"); } void thefunc(void) __attribute__((ifunc("resolver"))); void *resolver(void) { return &impl; } int main(void) { thefunc(); void (*theptr)(void) = &thefunc; theptr(); } work on Linux glibc. -fpie will crash because the compiler and the linker do not agree on the value which r30 stores (_GLOBAL_OFFSET_TABLE_ vs .got2+0x8000). Differential Revision: https://reviews.llvm.org/D71621
* [ELF][PPC64] Implement IPLT code sequence for non-preemptible IFUNCFangrui Song2019-12-291-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Non-preemptible IFUNC are placed in in.iplt (.glink on EM_PPC64). If there is a non-GOT non-PLT relocation, for pointer equality, we change the type of the symbol from STT_IFUNC and STT_FUNC and bind it to the .glink entry. On EM_386, EM_X86_64, EM_ARM, and EM_AARCH64, the PLT code sequence loads the address from its associated .got.plt slot. An IPLT also has an associated .got.plt slot and can use the same code sequence. On EM_PPC64, the PLT code sequence is actually a bl instruction in .glink . It jumps to `__glink_PLTresolve` (the PLT header). and `__glink_PLTresolve` computes the .plt slot (relocated by R_PPC64_JUMP_SLOT). An IPLT does not have an associated R_PPC64_JUMP_SLOT, so we cannot use `bl` in .iplt . Instead, create a call stub which has a similar code sequence as PPC64PltCallStub. We don't save the TOC pointer, so such scenarios will not work: a function pointer to a non-preemptible ifunc, which resolves to a function defined in another DSO. This is the restriction described by https://sourceware.org/glibc/wiki/GNU_IFUNC (though on many architectures it works in practice): Requirement (a): Resolver must be defined in the same translation unit as the implementations. If an ifunc is taken address but not called, technically we don't need an entry for it, but we currently do that. This patch makes // clang -fuse-ld=lld -fno-pie -no-pie a.c // clang -fuse-ld=lld -fPIE -pie a.c #include <stdio.h> static void impl(void) { puts("meow"); } void thefunc(void) __attribute__((ifunc("resolver"))); void *resolver(void) { return &impl; } int main(void) { thefunc(); void (*theptr)(void) = &thefunc; theptr(); } work on Linux glibc and FreeBSD. Calling a function pointer pointing to a Non-preemptible IFUNC never worked before. Differential Revision: https://reviews.llvm.org/D71509
* [ELF][PPC64] Support long branch thunks with addendsFangrui Song2019-12-051-18/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes PPC64 part of PR40438 // clang -target ppc64le -c a.cc // .text.unlikely may be placed in a separate output section (via -z keep-text-section-prefix) // The distance between bar in .text.unlikely and foo in .text may be larger than 32MiB. static void foo() {} __attribute__((section(".text.unlikely"))) static int bar() { foo(); return 0; } __attribute__((used)) static int dummy = bar(); This patch makes such thunks with addends work for PPC64. AArch64: .text -> `__AArch64ADRPThunk_ (adrp x16, ...; add x16, x16, ...; br x16)` -> target PPC64: .text -> `__long_branch_ (addis 12, 2, ...; ld 12, ...(12); mtctr 12; bctr)` -> target AArch64 can leverage ADRP to jump to the target directly, but PPC64 needs to load an address from .branch_lt . Before Power ISA v3.0, the PC-relative ADDPCIS was not available. .branch_lt was invented to work around the limitation. Symbol::ppc64BranchltIndex is replaced by PPC64LongBranchTargetSection::entry_index which take addends into consideration. The tests are rewritten: ppc64-long-branch.s tests -no-pie and ppc64-long-branch-pi.s tests -pie and -shared. Reviewed By: sfertile Differential Revision: https://reviews.llvm.org/D70937
* [ELF][AArch64] Support R_AARCH64_{CALL26,JUMP26} range extension thunks with ↵Fangrui Song2019-12-021-25/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix a few typos in lld/ELF to cycle botsNico Weber2019-10-281-1/+1
|
* [ELF] Fix variable names in comments after VariableName -> variableName changeFangrui Song2019-07-161-2/+2
| | | | | | Also fix some typos. llvm-svn: 366181
* Fix parameter name comments using clang-tidy. NFC.Rui Ueyama2019-07-161-1/+1
| | | | | | | | | | | | | | | | | | | | | This patch applies clang-tidy's bugprone-argument-comment tool to LLVM, clang and lld source trees. Here is how I created this patch: $ git clone https://github.com/llvm/llvm-project.git $ cd llvm-project $ mkdir build $ cd build $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \ -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \ -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm $ ninja $ parallel clang-tidy -checks='-*,bugprone-argument-comment' \ -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \ ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h} llvm-svn: 366177
* [Coding style change][lld] Rename variables for non-ELF portsRui Ueyama2019-07-111-16/+16
| | | | | | | | | | | This patch does the same thing as r365595 to other subdirectories, which completes the naming style change for the entire lld directory. With this, the naming style conversion is complete for lld. Differential Revision: https://reviews.llvm.org/D64473 llvm-svn: 365730
* [Coding style change] Rename variables so that they start with a lowercase ↵Rui Ueyama2019-07-101-404/+404
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Avoid identifiers that are different only in case. NFC.Rui Ueyama2019-07-031-8/+8
| | | | llvm-svn: 365004
* ELF: Create synthetic sections for loadable partitions.Peter Collingbourne2019-06-071-3/+4
| | | | | | | | | | | | | | | We create several types of synthetic sections for loadable partitions, including: - The dynamic symbol table. This allows code outside of the loadable partitions to find entry points with dlsym. - Creating a dynamic symbol table also requires the creation of several other synthetic sections for the partition, such as the dynamic table and hash table sections. - The partition's ELF header is represented as a synthetic section in the combined output file, and will be used by llvm-objcopy to extract partitions. Differential Revision: https://reviews.llvm.org/D62350 llvm-svn: 362819
* [PPC32] Improve the 32-bit PowerPC portFangrui Song2019-06-061-17/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many -static/-no-pie/-shared/-pie applications linked against glibc or musl should work with this patch. This also helps FreeBSD PowerPC64 to migrate their lib32 (PR40888). * Fix default image base and max page size. * Support new-style Secure PLT (see below). Old-style BSS PLT is not implemented, so it is not suitable for FreeBSD rtld now because it doesn't support Secure PLT yet. * Support more initial relocation types: R_PPC_ADDR32, R_PPC_REL16*, R_PPC_LOCAL24PC, R_PPC_PLTREL24, and R_PPC_GOT16. The addend of R_PPC_PLTREL24 is special: it decides the call stub PLT type but it should be ignored for the computation of target symbol VA. * Support GNU ifunc * Support .glink used for lazy PLT resolution in glibc * Add a new thunk type: PPC32PltCallStub that is similar to PPC64PltCallStub. It is used by R_PPC_REL24 and R_PPC_PLTREL24. A PLT stub used in -fPIE/-fPIC usually loads an address relative to .got2+0x8000 (-fpie/-fpic code uses _GLOBAL_OFFSET_TABLE_ relative addresses). Two .got2 sections in two object files have different addresses, thus a PLT stub can't be shared by two object files. To handle this incompatibility, change the parameters of Thunk::isCompatibleWith to `const InputSection &, const Relocation &`. PowerPC psABI specified an old-style .plt (BSS PLT) that is both writable and executable. Linkers don't make separate RW- and RWE segments, which causes all initially writable memory (think .data) executable. This is a big security concern so a new PLT scheme (secure PLT) was developed to address the security issue. TLS will be implemented in D62940. glibc older than ~2012 requires .rela.dyn to include .rela.plt, it can not handle the DT_RELA+DT_RELASZ == DT_JMPREL case correctly. A hack (not included in this patch) in LinkerScript.cpp addOrphanSections() to work around the issue: if (Config->EMachine == EM_PPC) { // Older glibc assumes .rela.dyn includes .rela.plt Add(In.RelaDyn); if (In.RelaPlt->isLive() && !In.RelaPlt->Parent) In.RelaDyn->getParent()->addSection(In.RelaPlt); } Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D62464 llvm-svn: 362721
* [mips] Remove redundant setup of less-significant bit. NFCSimon Atanasyan2019-03-131-2/+2
| | | | | | | The less-significant bit for microMIPS symbols configured in the `getSymVA` function. Do not need to setup it once again. llvm-svn: 356058
* 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] Implement option to force PIC compatible ThunksPeter Smith2019-01-161-5/+5
| | | | | | | | | | | | | | | | | By default LLD will generate position independent Thunks when the --pie or --shared option is used. Reference to absolute addresses is permitted in other cases. For some embedded systems position independent thunks are needed for code that executes before the MMU has been set up. The option --pic-veneer is used by ld.bfd to force position independent thunks. The patch adds --pic-veneer as the option is needed for the Linux kernel on Arm. fixes pr39886 Differential Revision: https://reviews.llvm.org/D55505 llvm-svn: 351326
* [ELF] Fix ARM and Thumb V7PILongThunk overflow behavior.Peter Smith2019-01-101-2/+2
| | | | | | | | | | | | | | | | | | 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][ARM] Add support for architecture v6m thunksPeter Smith2018-12-171-5/+92
| | | | | | | | | | | | | | | | | | | | | | ARM Architecture v6m is used by the smallest microcontrollers such as the cortex-m0. It is Thumb only (no Thumb 2) which prevents it from using the existing Thumb 2 range extension thunks as these use the Thumb 2 movt/movw instructions. Range extension thunks are not usually needed for microcontrollers due to the small amount of flash and ram on the device, however if code is copied from flash into ram then a range extension thunk is required to call that code. This change adds support for v6m range extension thunks. The procedure call standard APCS permits a thunk to corrupt the intra-procedural scratch register r12 (referred to as ip in the APCS). Most Thumb instructions do not permit access to high registers (r8 - r15) so the thunks must spill some low registers (r0 - r7) to perform the control transfer. Fixes pr39922 Differential Revision: https://reviews.llvm.org/D55555 llvm-svn: 349337
* [PPC64] Long branch thunks.Sean Fertile2018-11-141-12/+71
| | | | | | | | | | | | | | | | | | On PowerPC64, when a function call offset is too large to encode in a call instruction the address is stored in a table in the data segment. A thunk is used to load the branch target address from the table relative to the TOC-pointer and indirectly branch to the callee. When linking position-dependent code the addresses are stored directly in the table, for position-independent code the table is allocated and filled in at load time by the dynamic linker. For position-independent code the branch targets could have gone in the .got.plt but using the .branch_lt section for both position dependent and position independent binaries keeps it consitent and helps keep this PPC64 specific logic seperated from the target-independent code handling the .got.plt. Differential Revision: https://reviews.llvm.org/D53408 llvm-svn: 346877
* [ELF] [ARM] Don't mix 'ip' and 'r12' as names for the same register in ↵Martin Storsjo2018-08-311-4/+4
| | | | | | comments. NFC. llvm-svn: 341179
* [ELF] Add support for Armv5 and Armv6 compatible ThunksPeter Smith2018-08-201-3/+113
| | | | | | | | | | | | | | | | 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 Thunks: fix build error: missing 'overrides'Roman Lebedev2018-05-061-1/+1
| | | | llvm-svn: 331608
* [PPC64] Emit plt call stubs to the text section rather then the plt section.Sean Fertile2018-05-061-4/+51
| | | | | | | | | | | | | | | | | | On PowerPC calls to functions through the plt must be done through a call stub that is responsible for: 1) Saving the toc pointer to the stack. 2) Loading the target functions address from the plt into both r12 and the count register. 3) Indirectly branching to the target function. Previously we have been emitting these call stubs to the .plt section, however the .plt section should be reserved for the lazy symbol resolution stubs. This patch moves the call stubs to the text section by moving the implementation from writePlt to the thunk framework. Differential Revision: https://reviews.llvm.org/D46204 llvm-svn: 331607
* ELF: Add support for short thunks on ARM.Peter Collingbourne2018-03-291-44/+151
| | | | | | | | | | | A short thunk uses a direct branch (b or b.w) instruction, and is used when the target has the same thumbness as the thunk and is within direct branch range (32MB for ARM, 16MB for Thumb-2). Reduces the size of Chromium for Android's .text section by around 160KB. Differential Revision: https://reviews.llvm.org/D44963 llvm-svn: 328846
* ELF: Allow thunks to change size. NFCI.Peter Collingbourne2018-03-291-42/+45
| | | | | | Differential Revision: https://reviews.llvm.org/D44962 llvm-svn: 328841
* ELF: Make required Thunk methods pure virtual and remove an unused argument. ↵Peter Collingbourne2018-03-281-27/+27
| | | | | | | | | | | NFC. Also make certain Thunk methods non-const as this will be required for an upcoming change. Differential Revision: https://reviews.llvm.org/D44961 llvm-svn: 328732
* [ELF] Convert {read,write}*be to endianness-aware read/write.Fangrui Song2018-03-091-12/+11
| | | | | | | | Subscribers: emaste, nemanjai, arichardson, kbarton, llvm-commits Differential Revision: https://reviews.llvm.org/D44227 llvm-svn: 327156
* Use references instead of pointers. NFC.Rafael Espindola2017-12-191-16/+16
| | | | | | | These values are trivially never null. While at it, also use InputSection instead of InputSectionBase when possible. llvm-svn: 321126
* Replace a dyn_cast with a cast. NFC.Rafael Espindola2017-11-291-2/+2
| | | | llvm-svn: 319361
* Replace another dyn_cast with a cast.Rafael Espindola2017-11-291-2/+2
| | | | llvm-svn: 319335
* Replace a dyn_cast with a cast.Rafael Espindola2017-11-291-2/+2
| | | | | | It is always accessed, so there is no value in a dyn_cast. llvm-svn: 319334
* [ELF][AArch64] Add support for AArch64 range thunks.Peter Smith2017-11-291-1/+82
| | | | | | | | | | | | 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
* Move Memory.{h,cpp} to Common.Rui Ueyama2017-11-281-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D40571 llvm-svn: 319221
* [MIPS] Setup less-significant bit in a symbol value in microMIPS thunksSimon Atanasyan2017-11-091-2/+2
| | | | | | The less-significant bit signals about microMIPS code for jump/branch instructions. llvm-svn: 317778
* ELF: Merge DefinedRegular and Defined.Peter Collingbourne2017-11-061-3/+3
| | | | | | | | | 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-12/+12
| | | | | | | | | | | | | 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] Add support for multiple passes to createThunks()Peter Smith2017-10-271-8/+8
| | | | | | | | | | | | | This change allows Thunks to be added on multiple passes. To do this we must merge only the thunks added in each pass, and deal with thunks that have drifted out of range of their callers. A thunk may end out of range of its caller if enough thunks are added in between the caller and the thunk. To handle this we create another thunk. Differential Revision: https://reviews.llvm.org/D34692 llvm-svn: 316754
* [ELF] Introduce range extension thunks for ARMPeter Smith2017-10-271-0/+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
* [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-19/+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
* [MIPS] Generate thunks for microMIPS codeSimon Atanasyan2017-10-031-2/+80
| | | | | | | | 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
* [ELF] Fix edge condition in thunk offset calculationShoaib Meenai2017-09-211-7/+9
| | | | | | | | | | | | | | | | | | | | | For ARM thunks, the `movt` half of the relocation was using an incorrect offset (it was off by 4 bytes). The original intent seems to have been for the offset to have been relative to the current instruction, in which case the difference of 4 makes sense. As the code stands, however, the offset is always calculated relative to the start of the thunk (`P`), and so the `movw` and `movt` halves should use the same offset. This requires a very particular offset between the thunk and its target to be triggered, and it results in the `movt` half of the relocation being off-by-one. The tests here use ARM-Thumb interworking thunks, since those are the only ARM thunks currently implemented. I actually encountered this with a range extension thunk (having Peter's patches cherry-picked locally), but the underlying issue is identical. Differential Revision: https://reviews.llvm.org/D38112 llvm-svn: 313915
* [ELF] - Fix member name: alignment -> Alignment. NFC.George Rimar2017-07-181-2/+2
| | | | llvm-svn: 308300
* [ELF] - Apply clang-format. NFC.George Rimar2017-07-181-12/+6
| | | | llvm-svn: 308297
* [ELF] Introduce Thunk reuse compatibilityPeter Smith2017-07-051-0/+26
| | | | | | | | | | | | | | | | On ARM the interworking thunks are only produced for branch instructions that can't be changed into a blx instruction so only Thumb callers would call Thumb thunks and only ARM callers would call ARM thunks. With range extension thunks branch and link instructions may need a Thunk. These instructions can be rewritten as a blx and can use either ARM or Thumb thunks. We introduce an isCompatibleWith() function so that a caller can check if an existing Thunk is compatible before reusing it. Differential Revision: https://reviews.llvm.org/D34035 llvm-svn: 307132
* [ELF] Do not use `this` to access members of non-template class. NFCSimon Atanasyan2017-07-041-3/+3
| | | | llvm-svn: 307083
* [ELF] Be more precise about Thumb state bit in ARM thunksPeter Smith2017-06-091-3/+3
| | | | | | | | | The symbols generated for Thunks have type STT_FUNC, to permit a thunk to be reused via a blx instruction the Thumb bit (0) needs to be set properly. Differential Revision: https://reviews.llvm.org/D34036 llvm-svn: 305065
* 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
* [ELF] - Detemplate Thunk creation.George Rimar2017-05-171-72/+56
| | | | | | | | | Nothing special here, just detemplates code that became possible to detemplate after recent commits in a straghtforward way. Differential revision: https://reviews.llvm.org/D33234 llvm-svn: 303237
OpenPOWER on IntegriCloud