summaryrefslogtreecommitdiffstats
path: root/lld/ELF/Thunks.h
Commit message (Collapse)AuthorAgeFilesLines
* [ELF][PPC32] Implement IPLT code sequence for non-preemptible IFUNCFangrui Song2019-12-291-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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][AArch64] Support R_AARCH64_{CALL26,JUMP26} range extension thunks with ↵Fangrui Song2019-12-021-3/+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
* [Coding style change] Rename variables so that they start with a lowercase ↵Rui Ueyama2019-07-101-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [PPC32] Improve the 32-bit PowerPC portFangrui Song2019-06-061-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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: Allow thunks to change size. NFCI.Peter Collingbourne2018-03-291-3/+11
| | | | | | 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-3/+3
| | | | | | | | | | | 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: 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-5/+5
| | | | | | | | | | | | | 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-3/+3
| | | | | | | | | | | | | 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
* Define RelType to represent relocation types.Rui Ueyama2017-10-111-3/+3
| | | | | | | | | | | | | | | | | | 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] - Fix member name: alignment -> Alignment. NFC.George Rimar2017-07-181-1/+1
| | | | llvm-svn: 308300
* [ELF] Introduce Thunk reuse compatibilityPeter Smith2017-07-051-0/+4
| | | | | | | | | | | | | | | | 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] - Detemplate Thunk creation.George Rimar2017-05-171-1/+1
| | | | | | | | | 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
* [ELF] Detemplate ThunkSection and Thunk classes. NFC.George Rimar2017-03-161-5/+5
| | | | llvm-svn: 297939
* Merge OutputSectionBase and OutputSection. NFC.Rafael Espindola2017-02-241-1/+0
| | | | | | | Now that all special sections are SyntheticSections, we only need one OutputSection class. llvm-svn: 296127
* Make InputSection a class. NFC.Rafael Espindola2017-02-231-1/+1
| | | | | | | | | With the current design an InputSection is basically anything that goes directly in a OutputSection. That includes plain input section but also synthetic sections, so this should probably not be a template. llvm-svn: 295993
* [ELF] Use SyntheticSections for ThunksPeter Smith2017-02-011-17/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | Thunks are now implemented by redirecting the relocation to the symbol S, to a symbol TS in a Thunk. The Thunk will transfer control to S. This has the following implications: - All the side-effects of Thunks happen within createThunks() - Thunks are no longer stored in InputSections and Symbols no longer need to hold a pointer to a Thunk - The synthetic Thunk sections need to be merged into OutputSections This implementation is almost a direct conversion of the existing Thunks with the following exceptions: - Mips LA25 Thunks are placed before the InputSection that defines the symbol that needs a Thunk. - All ARM Thunks are placed at the end of the OutputSection of the first caller to the Thunk. Range extension Thunks are not supported yet so it is optimistically assumed that all Thunks can be reused. This is a recommit of r293283 with a fixed comparison predicate as std::merge requires a strict weak ordering. Differential revision: https://reviews.llvm.org/D29327 llvm-svn: 293757
* Revert "[ELF][ARM] Use SyntheticSections for Thunks"Rui Ueyama2017-01-281-21/+17
| | | | | | This reverts commit r293283 because it broke MSVC build. llvm-svn: 293352
* [ELF][ARM] Use SyntheticSections for ThunksPeter Smith2017-01-271-17/+21
| | | | | | | | | | | | | | | | | | | | | | | | Thunks are now implemented by redirecting the relocation to the symbol S, to a symbol TS in a Thunk. The Thunk will transfer control to S. This has the following implications: - All the side-effects of Thunks happen within createThunks() - Thunks are no longer stored in InputSections and Symbols no longer need to hold a pointer to a Thunk - The synthetic Thunk sections need to be merged into OutputSections This implementation is almost a direct conversion of the existing Thunks with the following exceptions: - Mips LA25 Thunks are placed before the InputSection that defines the symbol that needs a Thunk. - All ARM Thunks are placed at the end of the OutputSection of the first caller to the Thunk. Range extension Thunks are not supported yet so it is optimistically assumed that all Thunks can be reused. Differential Revision: https://reviews.llvm.org/D29129 llvm-svn: 293283
* Attempt to fix buildbots.Rui Ueyama2016-07-091-2/+2
| | | | llvm-svn: 275001
* Remove unused forward declarations.Rui Ueyama2016-07-091-2/+0
| | | | llvm-svn: 274998
* Make ARM thunks consistent with MIPS in coding style.Rui Ueyama2016-07-091-3/+6
| | | | | | | | Although they are in the same .cpp file, the way they were written were slightly different, so they looked more different than they were. This patch makes their styles consistent. llvm-svn: 274996
* Recommit R274836 Add Thunk support framework for ARM and MipsPeter Smith2016-07-081-0/+55
| | | | | | | | | | | The TinyPtrVector of const Thunk<ELFT>* in InputSections.h can cause build failures on certain compiler/library combinations when Thunk<ELFT> is not a complete type or is an abstract class. Fixed by making Thunk<ELFT> non Abstract. type or is an abstract class llvm-svn: 274863
* Revert R274836 Add Thunk support framework for ARM and MipsPeter Smith2016-07-081-55/+0
| | | | | | | This seems to be causing a buildbot failure on lld-x86_64-freebsd. Will reproduce locally and fix. llvm-svn: 274841
* Add Thunk support framework for ARM and MipsPeter Smith2016-07-081-0/+55
Generalise the Mips LA25 Thunk code and implement ARM and Thumb interworking Thunks. - Introduce a new module Thunks.cpp to store the Target Specific Thunk implementations. - DefinedRegular and Shared have a ThunkData field to record Thunk. - A Target can have more than one type of Thunk. - Support PC-relative calls to Thunks. - Support Thunks to PLT entries. - Existing Mips LA25 Thunk code integrated. - Support for ARMv7A interworking Thunks. Limitations: - Only one Thunk per SymbolBody, this is sufficient for all currently implemented Thunks. - ARM thunks assume presence of V6T2 MOVT and MOVW instructions. Differential revision: http://reviews.llvm.org/D21891 llvm-svn: 274836
OpenPOWER on IntegriCloud