2017-06-17 01:32:43 +08:00
|
|
|
//===- PPC64.cpp ----------------------------------------------------------===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2017-06-17 01:32:43 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "Symbols.h"
|
|
|
|
#include "SyntheticSections.h"
|
|
|
|
#include "Target.h"
|
[ELF][PPC64] Implement IPLT code sequence for non-preemptible IFUNC
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
2019-12-14 10:30:21 +08:00
|
|
|
#include "Thunks.h"
|
[lld] unified COFF and ELF error handling on new Common/ErrorHandler
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
2017-10-26 06:28:38 +08:00
|
|
|
#include "lld/Common/ErrorHandler.h"
|
2017-06-17 01:32:43 +08:00
|
|
|
#include "llvm/Support/Endian.h"
|
|
|
|
|
|
|
|
using namespace llvm;
|
2018-03-20 01:40:14 +08:00
|
|
|
using namespace llvm::object;
|
|
|
|
using namespace llvm::support::endian;
|
2017-06-17 01:32:43 +08:00
|
|
|
using namespace llvm::ELF;
|
2019-10-07 16:31:18 +08:00
|
|
|
|
|
|
|
namespace lld {
|
|
|
|
namespace elf {
|
2017-06-17 01:32:43 +08:00
|
|
|
|
|
|
|
static uint64_t ppc64TocOffset = 0x8000;
|
2018-06-12 09:47:02 +08:00
|
|
|
static uint64_t dynamicThreadPointerOffset = 0x8000;
|
2017-06-17 01:32:43 +08:00
|
|
|
|
2018-08-21 23:13:53 +08:00
|
|
|
// The instruction encoding of bits 21-30 from the ISA for the Xform and Dform
|
|
|
|
// instructions that can be used as part of the initial exec TLS sequence.
|
|
|
|
enum XFormOpcd {
|
|
|
|
LBZX = 87,
|
|
|
|
LHZX = 279,
|
|
|
|
LWZX = 23,
|
|
|
|
LDX = 21,
|
|
|
|
STBX = 215,
|
|
|
|
STHX = 407,
|
|
|
|
STWX = 151,
|
|
|
|
STDX = 149,
|
|
|
|
ADD = 266,
|
|
|
|
};
|
|
|
|
|
|
|
|
enum DFormOpcd {
|
|
|
|
LBZ = 34,
|
2018-09-20 08:26:44 +08:00
|
|
|
LBZU = 35,
|
2018-08-21 23:13:53 +08:00
|
|
|
LHZ = 40,
|
2018-09-20 08:26:44 +08:00
|
|
|
LHZU = 41,
|
|
|
|
LHAU = 43,
|
2018-08-21 23:13:53 +08:00
|
|
|
LWZ = 32,
|
2018-09-20 08:26:44 +08:00
|
|
|
LWZU = 33,
|
|
|
|
LFSU = 49,
|
2018-08-21 23:13:53 +08:00
|
|
|
LD = 58,
|
2018-09-20 08:26:44 +08:00
|
|
|
LFDU = 51,
|
2018-08-21 23:13:53 +08:00
|
|
|
STB = 38,
|
2018-09-20 08:26:44 +08:00
|
|
|
STBU = 39,
|
2018-08-21 23:13:53 +08:00
|
|
|
STH = 44,
|
2018-09-20 08:26:44 +08:00
|
|
|
STHU = 45,
|
2018-08-21 23:13:53 +08:00
|
|
|
STW = 36,
|
2018-09-20 08:26:44 +08:00
|
|
|
STWU = 37,
|
|
|
|
STFSU = 53,
|
|
|
|
STFDU = 55,
|
2018-08-21 23:13:53 +08:00
|
|
|
STD = 62,
|
|
|
|
ADDI = 14
|
|
|
|
};
|
|
|
|
|
2019-10-07 16:31:18 +08:00
|
|
|
uint64_t getPPC64TocBase() {
|
2017-06-17 01:32:43 +08:00
|
|
|
// The TOC consists of sections .got, .toc, .tocbss, .plt in that order. The
|
|
|
|
// TOC starts where the first of these sections starts. We always create a
|
|
|
|
// .got when we see a relocation that uses it, so for us the start is always
|
|
|
|
// the .got.
|
2018-09-26 03:26:58 +08:00
|
|
|
uint64_t tocVA = in.got->getVA();
|
2017-06-17 01:32:43 +08:00
|
|
|
|
|
|
|
// Per the ppc64-elf-linux ABI, The TOC base is TOC value plus 0x8000
|
|
|
|
// thus permitting a full 64 Kbytes segment. Note that the glibc startup
|
|
|
|
// code (crt1.o) assumes that you can get from the TOC base to the
|
|
|
|
// start of the .toc section with only a single (signed) 16-bit relocation.
|
|
|
|
return tocVA + ppc64TocOffset;
|
|
|
|
}
|
|
|
|
|
2019-10-07 16:31:18 +08:00
|
|
|
unsigned getPPC64GlobalEntryToLocalEntryOffset(uint8_t stOther) {
|
2018-09-20 08:26:47 +08:00
|
|
|
// The offset is encoded into the 3 most significant bits of the st_other
|
|
|
|
// field, with some special values described in section 3.4.1 of the ABI:
|
|
|
|
// 0 --> Zero offset between the GEP and LEP, and the function does NOT use
|
|
|
|
// the TOC pointer (r2). r2 will hold the same value on returning from
|
|
|
|
// the function as it did on entering the function.
|
|
|
|
// 1 --> Zero offset between the GEP and LEP, and r2 should be treated as a
|
|
|
|
// caller-saved register for all callers.
|
|
|
|
// 2-6 --> The binary logarithm of the offset eg:
|
|
|
|
// 2 --> 2^2 = 4 bytes --> 1 instruction.
|
|
|
|
// 6 --> 2^6 = 64 bytes --> 16 instructions.
|
|
|
|
// 7 --> Reserved.
|
|
|
|
uint8_t gepToLep = (stOther >> 5) & 7;
|
|
|
|
if (gepToLep < 2)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
// The value encoded in the st_other bits is the
|
|
|
|
// log-base-2(offset).
|
|
|
|
if (gepToLep < 7)
|
|
|
|
return 1 << gepToLep;
|
|
|
|
|
|
|
|
error("reserved value of 7 in the 3 most-significant-bits of st_other");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-10-07 16:31:18 +08:00
|
|
|
bool isPPC64SmallCodeModelTocReloc(RelType type) {
|
2019-02-12 23:35:49 +08:00
|
|
|
// The only small code model relocations that access the .toc section.
|
|
|
|
return type == R_PPC64_TOC16 || type == R_PPC64_TOC16_DS;
|
2019-01-25 02:17:40 +08:00
|
|
|
}
|
|
|
|
|
[PPC64] toc-indirect to toc-relative relaxation
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
2019-05-07 12:26:05 +08:00
|
|
|
// Find the R_PPC64_ADDR64 in .rela.toc with matching offset.
|
|
|
|
template <typename ELFT>
|
|
|
|
static std::pair<Defined *, int64_t>
|
|
|
|
getRelaTocSymAndAddend(InputSectionBase *tocSec, uint64_t offset) {
|
|
|
|
if (tocSec->numRelocations == 0)
|
|
|
|
return {};
|
|
|
|
|
|
|
|
// .rela.toc contains exclusively R_PPC64_ADDR64 relocations sorted by
|
|
|
|
// r_offset: 0, 8, 16, etc. For a given Offset, Offset / 8 gives us the
|
|
|
|
// relocation index in most cases.
|
|
|
|
//
|
|
|
|
// In rare cases a TOC entry may store a constant that doesn't need an
|
|
|
|
// R_PPC64_ADDR64, the corresponding r_offset is therefore missing. Offset / 8
|
|
|
|
// points to a relocation with larger r_offset. Do a linear probe then.
|
|
|
|
// Constants are extremely uncommon in .toc and the extra number of array
|
|
|
|
// accesses can be seen as a small constant.
|
|
|
|
ArrayRef<typename ELFT::Rela> relas = tocSec->template relas<ELFT>();
|
|
|
|
uint64_t index = std::min<uint64_t>(offset / 8, relas.size() - 1);
|
|
|
|
for (;;) {
|
|
|
|
if (relas[index].r_offset == offset) {
|
|
|
|
Symbol &sym = tocSec->getFile<ELFT>()->getRelocTargetSym(relas[index]);
|
|
|
|
return {dyn_cast<Defined>(&sym), getAddend<ELFT>(relas[index])};
|
|
|
|
}
|
|
|
|
if (relas[index].r_offset < offset || index == 0)
|
|
|
|
break;
|
|
|
|
--index;
|
|
|
|
}
|
|
|
|
return {};
|
|
|
|
}
|
|
|
|
|
|
|
|
// When accessing a symbol defined in another translation unit, compilers
|
|
|
|
// reserve a .toc entry, allocate a local label and generate toc-indirect
|
|
|
|
// instuctions:
|
|
|
|
//
|
|
|
|
// 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
|
|
|
|
//
|
|
|
|
// If var is defined, non-preemptable and addressable with a 32-bit signed
|
|
|
|
// offset from the toc base, the address of var can be computed by adding an
|
|
|
|
// offset to the toc base, saving a load.
|
|
|
|
//
|
|
|
|
// 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
|
|
|
|
//
|
|
|
|
// Returns true if the relaxation is performed.
|
2020-01-23 11:42:54 +08:00
|
|
|
bool tryRelaxPPC64TocIndirection(const Relocation &rel, uint8_t *bufLoc) {
|
[PPC64] toc-indirect to toc-relative relaxation
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
2019-05-07 12:26:05 +08:00
|
|
|
assert(config->tocOptimize);
|
|
|
|
if (rel.addend < 0)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// If the symbol is not the .toc section, this isn't a toc-indirection.
|
|
|
|
Defined *defSym = dyn_cast<Defined>(rel.sym);
|
|
|
|
if (!defSym || !defSym->isSection() || defSym->section->name != ".toc")
|
|
|
|
return false;
|
|
|
|
|
|
|
|
Defined *d;
|
|
|
|
int64_t addend;
|
|
|
|
auto *tocISB = cast<InputSectionBase>(defSym->section);
|
|
|
|
std::tie(d, addend) =
|
|
|
|
config->isLE ? getRelaTocSymAndAddend<ELF64LE>(tocISB, rel.addend)
|
|
|
|
: getRelaTocSymAndAddend<ELF64BE>(tocISB, rel.addend);
|
|
|
|
|
|
|
|
// Only non-preemptable defined symbols can be relaxed.
|
2019-08-13 17:43:40 +08:00
|
|
|
if (!d || d->isPreemptible)
|
[PPC64] toc-indirect to toc-relative relaxation
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
2019-05-07 12:26:05 +08:00
|
|
|
return false;
|
|
|
|
|
2019-08-13 17:43:40 +08:00
|
|
|
// R_PPC64_ADDR64 should have created a canonical PLT for the non-preemptable
|
|
|
|
// ifunc and changed its type to STT_FUNC.
|
|
|
|
assert(!d->isGnuIFunc());
|
|
|
|
|
[PPC64] toc-indirect to toc-relative relaxation
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
2019-05-07 12:26:05 +08:00
|
|
|
// Two instructions can materialize a 32-bit signed offset from the toc base.
|
|
|
|
uint64_t tocRelative = d->getVA(addend) - getPPC64TocBase();
|
|
|
|
if (!isInt<32>(tocRelative))
|
|
|
|
return false;
|
|
|
|
|
2020-01-23 13:39:16 +08:00
|
|
|
// Add PPC64TocOffset that will be subtracted by PPC64::relocate().
|
2020-01-23 11:42:54 +08:00
|
|
|
target->relaxGot(bufLoc, rel, tocRelative + ppc64TocOffset);
|
[PPC64] toc-indirect to toc-relative relaxation
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
2019-05-07 12:26:05 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-06-17 01:32:43 +08:00
|
|
|
namespace {
|
|
|
|
class PPC64 final : public TargetInfo {
|
|
|
|
public:
|
|
|
|
PPC64();
|
[PPC64] Set the number of relocations processed for R_PPC64_TLS[GL]D to 2
Summary:
R_PPC64_TLSGD and R_PPC64_TLSLD are used as markers on TLS code sequences. After GD-to-IE or GD-to-LE relaxation, the next relocation R_PPC64_REL24 should be skipped to not create a false dependency on __tls_get_addr. When linking statically, the false dependency may cause an "undefined symbol: __tls_get_addr" error.
R_PPC64_GOT_TLSGD16_HA
R_PPC64_GOT_TLSGD16_LO
R_PPC64_TLSGD R_TLSDESC_CALL
R_PPC64_REL24 __tls_get_addr
Reviewers: ruiu, sfertile, syzaara, espindola
Reviewed By: sfertile
Subscribers: emaste, nemanjai, arichardson, kbarton, jsji, llvm-commits, tamur
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57673
llvm-svn: 353262
2019-02-06 10:00:24 +08:00
|
|
|
int getTlsGdRelaxSkip(RelType type) const override;
|
2018-03-20 01:40:14 +08:00
|
|
|
uint32_t calcEFlags() const override;
|
2017-11-04 05:21:47 +08:00
|
|
|
RelExpr getRelExpr(RelType type, const Symbol &s,
|
2017-06-17 01:32:43 +08:00
|
|
|
const uint8_t *loc) const override;
|
[ELF][ARM][AARCH64][MIPS][PPC] Simplify the logic to create R_*_RELATIVE for 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
2019-06-20 22:00:08 +08:00
|
|
|
RelType getDynRel(RelType type) const override;
|
2018-05-09 10:07:53 +08:00
|
|
|
void writePltHeader(uint8_t *buf) const override;
|
2019-12-18 05:43:04 +08:00
|
|
|
void writePlt(uint8_t *buf, const Symbol &sym,
|
|
|
|
uint64_t pltEntryAddr) const override;
|
[ELF][PPC64] Implement IPLT code sequence for non-preemptible IFUNC
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
2019-12-14 10:30:21 +08:00
|
|
|
void writeIplt(uint8_t *buf, const Symbol &sym,
|
|
|
|
uint64_t pltEntryAddr) const override;
|
2020-01-23 13:39:16 +08:00
|
|
|
void relocate(uint8_t *loc, const Relocation &rel,
|
|
|
|
uint64_t val) const override;
|
2018-03-20 01:40:14 +08:00
|
|
|
void writeGotHeader(uint8_t *buf) const override;
|
2018-05-07 03:13:29 +08:00
|
|
|
bool needsThunk(RelExpr expr, RelType type, const InputFile *file,
|
2019-11-23 16:57:54 +08:00
|
|
|
uint64_t branchAddr, const Symbol &s,
|
|
|
|
int64_t a) const override;
|
2019-05-10 13:51:00 +08:00
|
|
|
uint32_t getThunkSectionSpacing() const override;
|
2018-11-15 01:56:43 +08:00
|
|
|
bool inBranchRange(RelType type, uint64_t src, uint64_t dst) const override;
|
[PPC64] Thread-local storage general-dynamic to initial-exec relaxation.
Patch adds support for relaxing the general-dynamic tls sequence to
initial-exec.
the relaxation performs the following transformation:
addis r3, r2, x@got@tlsgd@ha --> addis r3, r2, x@got@tprel@ha
addi r3, r3, x@got@tlsgd@l --> ld r3, x@got@tprel@l(r3)
bl __tls_get_addr(x@tlsgd) --> nop
nop --> add r3, r3, r13
and instead of emitting a DTPMOD64/DTPREL64 pair for x, we emit a single
R_PPC64_TPREL64.
Differential Revision: https://reviews.llvm.org/D48090
llvm-svn: 335651
2018-06-27 03:38:18 +08:00
|
|
|
RelExpr adjustRelaxExpr(RelType type, const uint8_t *data,
|
|
|
|
RelExpr expr) const override;
|
2020-01-23 11:42:54 +08:00
|
|
|
void relaxGot(uint8_t *loc, const Relocation &rel,
|
|
|
|
uint64_t val) const override;
|
|
|
|
void relaxTlsGdToIe(uint8_t *loc, const Relocation &rel,
|
|
|
|
uint64_t val) const override;
|
|
|
|
void relaxTlsGdToLe(uint8_t *loc, const Relocation &rel,
|
|
|
|
uint64_t val) const override;
|
|
|
|
void relaxTlsLdToLe(uint8_t *loc, const Relocation &rel,
|
|
|
|
uint64_t val) const override;
|
|
|
|
void relaxTlsIeToLe(uint8_t *loc, const Relocation &rel,
|
|
|
|
uint64_t val) const override;
|
[Coding style change] Rename variables so that they start with a lowercase 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
2019-07-10 13:00:37 +08:00
|
|
|
|
2018-10-17 01:13:01 +08:00
|
|
|
bool adjustPrologueForCrossSplitStack(uint8_t *loc, uint8_t *end,
|
|
|
|
uint8_t stOther) const override;
|
2017-06-17 01:32:43 +08:00
|
|
|
};
|
|
|
|
} // namespace
|
|
|
|
|
|
|
|
// Relocation masks following the #lo(value), #hi(value), #ha(value),
|
|
|
|
// #higher(value), #highera(value), #highest(value), and #highesta(value)
|
|
|
|
// macros defined in section 4.5.1. Relocation Types of the PPC-elf64abi
|
|
|
|
// document.
|
2018-06-13 08:50:17 +08:00
|
|
|
static uint16_t lo(uint64_t v) { return v; }
|
|
|
|
static uint16_t hi(uint64_t v) { return v >> 16; }
|
|
|
|
static uint16_t ha(uint64_t v) { return (v + 0x8000) >> 16; }
|
|
|
|
static uint16_t higher(uint64_t v) { return v >> 32; }
|
|
|
|
static uint16_t highera(uint64_t v) { return (v + 0x8000) >> 32; }
|
|
|
|
static uint16_t highest(uint64_t v) { return v >> 48; }
|
|
|
|
static uint16_t highesta(uint64_t v) { return (v + 0x8000) >> 48; }
|
2017-06-17 01:32:43 +08:00
|
|
|
|
2018-08-28 23:16:01 +08:00
|
|
|
// Extracts the 'PO' field of an instruction encoding.
|
|
|
|
static uint8_t getPrimaryOpCode(uint32_t encoding) { return (encoding >> 26); }
|
|
|
|
|
|
|
|
static bool isDQFormInstruction(uint32_t encoding) {
|
|
|
|
switch (getPrimaryOpCode(encoding)) {
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
case 56:
|
|
|
|
// The only instruction with a primary opcode of 56 is `lq`.
|
|
|
|
return true;
|
|
|
|
case 61:
|
|
|
|
// There are both DS and DQ instruction forms with this primary opcode.
|
|
|
|
// Namely `lxv` and `stxv` are the DQ-forms that use it.
|
|
|
|
// The DS 'XO' bits being set to 01 is restricted to DQ form.
|
|
|
|
return (encoding & 3) == 0x1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-09-20 08:26:44 +08:00
|
|
|
static bool isInstructionUpdateForm(uint32_t encoding) {
|
|
|
|
switch (getPrimaryOpCode(encoding)) {
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
case LBZU:
|
|
|
|
case LHAU:
|
|
|
|
case LHZU:
|
|
|
|
case LWZU:
|
|
|
|
case LFSU:
|
|
|
|
case LFDU:
|
|
|
|
case STBU:
|
|
|
|
case STHU:
|
|
|
|
case STWU:
|
|
|
|
case STFSU:
|
|
|
|
case STFDU:
|
|
|
|
return true;
|
|
|
|
// LWA has the same opcode as LD, and the DS bits is what differentiates
|
|
|
|
// between LD/LDU/LWA
|
|
|
|
case LD:
|
|
|
|
case STD:
|
|
|
|
return (encoding & 3) == 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-09-18 04:27:00 +08:00
|
|
|
// There are a number of places when we either want to read or write an
|
|
|
|
// instruction when handling a half16 relocation type. On big-endian the buffer
|
|
|
|
// pointer is pointing into the middle of the word we want to extract, and on
|
|
|
|
// little-endian it is pointing to the start of the word. These 2 helpers are to
|
|
|
|
// simplify reading and writing in that context.
|
2019-06-12 14:00:39 +08:00
|
|
|
static void writeFromHalf16(uint8_t *loc, uint32_t insn) {
|
|
|
|
write32(config->isLE ? loc : loc - 2, insn);
|
2018-09-18 04:27:00 +08:00
|
|
|
}
|
|
|
|
|
2019-06-12 14:00:39 +08:00
|
|
|
static uint32_t readFromHalf16(const uint8_t *loc) {
|
|
|
|
return read32(config->isLE ? loc : loc - 2);
|
2018-09-18 04:27:00 +08:00
|
|
|
}
|
|
|
|
|
2017-06-17 01:32:43 +08:00
|
|
|
PPC64::PPC64() {
|
2020-01-23 15:26:49 +08:00
|
|
|
copyRel = R_PPC64_COPY;
|
2018-04-03 03:47:21 +08:00
|
|
|
gotRel = R_PPC64_GLOB_DAT;
|
2018-09-26 16:11:34 +08:00
|
|
|
noneRel = R_PPC64_NONE;
|
2018-05-07 03:13:29 +08:00
|
|
|
pltRel = R_PPC64_JMP_SLOT;
|
2017-06-17 01:32:43 +08:00
|
|
|
relativeRel = R_PPC64_RELATIVE;
|
2018-05-25 00:32:14 +08:00
|
|
|
iRelativeRel = R_PPC64_IRELATIVE;
|
2019-06-11 20:59:30 +08:00
|
|
|
symbolicRel = R_PPC64_ADDR64;
|
2019-12-15 06:17:35 +08:00
|
|
|
pltHeaderSize = 60;
|
2018-05-09 10:07:53 +08:00
|
|
|
pltEntrySize = 4;
|
[ELF][PPC64] Implement IPLT code sequence for non-preemptible IFUNC
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
2019-12-14 10:30:21 +08:00
|
|
|
ipltEntrySize = 16; // PPC64PltCallStub::size
|
2018-03-20 01:40:14 +08:00
|
|
|
gotBaseSymInGotPlt = false;
|
2018-05-04 23:09:49 +08:00
|
|
|
gotHeaderEntriesNum = 1;
|
|
|
|
gotPltHeaderEntriesNum = 2;
|
2018-05-07 03:13:29 +08:00
|
|
|
needsThunks = true;
|
[Coding style change] Rename variables so that they start with a lowercase 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
2019-07-10 13:00:37 +08:00
|
|
|
|
2018-05-29 22:34:38 +08:00
|
|
|
tlsModuleIndexRel = R_PPC64_DTPMOD64;
|
|
|
|
tlsOffsetRel = R_PPC64_DTPREL64;
|
[Coding style change] Rename variables so that they start with a lowercase 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
2019-07-10 13:00:37 +08:00
|
|
|
|
2018-06-01 23:20:56 +08:00
|
|
|
tlsGotRel = R_PPC64_TPREL64;
|
[Coding style change] Rename variables so that they start with a lowercase 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
2019-07-10 13:00:37 +08:00
|
|
|
|
2018-10-17 01:13:01 +08:00
|
|
|
needsMoreStackNonSplit = false;
|
|
|
|
|
2017-06-17 01:32:43 +08:00
|
|
|
// We need 64K pages (at least under glibc/Linux, the loader won't
|
|
|
|
// set different permissions on a finer granularity than that).
|
|
|
|
defaultMaxPageSize = 65536;
|
|
|
|
|
|
|
|
// The PPC64 ELF ABI v1 spec, says:
|
|
|
|
//
|
|
|
|
// It is normally desirable to put segments with different characteristics
|
|
|
|
// in separate 256 Mbyte portions of the address space, to give the
|
|
|
|
// operating system full paging flexibility in the 64-bit address space.
|
|
|
|
//
|
|
|
|
// And because the lowest non-zero 256M boundary is 0x10000000, PPC64 linkers
|
|
|
|
// use 0x10000000 as the starting address.
|
|
|
|
defaultImageBase = 0x10000000;
|
2018-04-03 05:11:13 +08:00
|
|
|
|
2018-11-15 05:05:20 +08:00
|
|
|
write32(trapInstr.data(), 0x7fe00008);
|
2017-06-17 01:32:43 +08:00
|
|
|
}
|
|
|
|
|
[PPC64] Set the number of relocations processed for R_PPC64_TLS[GL]D to 2
Summary:
R_PPC64_TLSGD and R_PPC64_TLSLD are used as markers on TLS code sequences. After GD-to-IE or GD-to-LE relaxation, the next relocation R_PPC64_REL24 should be skipped to not create a false dependency on __tls_get_addr. When linking statically, the false dependency may cause an "undefined symbol: __tls_get_addr" error.
R_PPC64_GOT_TLSGD16_HA
R_PPC64_GOT_TLSGD16_LO
R_PPC64_TLSGD R_TLSDESC_CALL
R_PPC64_REL24 __tls_get_addr
Reviewers: ruiu, sfertile, syzaara, espindola
Reviewed By: sfertile
Subscribers: emaste, nemanjai, arichardson, kbarton, jsji, llvm-commits, tamur
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57673
llvm-svn: 353262
2019-02-06 10:00:24 +08:00
|
|
|
int PPC64::getTlsGdRelaxSkip(RelType type) const {
|
|
|
|
// A __tls_get_addr call instruction is marked with 2 relocations:
|
|
|
|
//
|
|
|
|
// R_PPC64_TLSGD / R_PPC64_TLSLD: marker relocation
|
|
|
|
// R_PPC64_REL24: __tls_get_addr
|
|
|
|
//
|
|
|
|
// After the relaxation we no longer call __tls_get_addr and should skip both
|
|
|
|
// relocations to not create a false dependence on __tls_get_addr being
|
|
|
|
// defined.
|
|
|
|
if (type == R_PPC64_TLSGD || type == R_PPC64_TLSLD)
|
|
|
|
return 2;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2018-03-20 01:40:14 +08:00
|
|
|
static uint32_t getEFlags(InputFile *file) {
|
2018-07-06 00:58:42 +08:00
|
|
|
if (config->ekind == ELF64BEKind)
|
|
|
|
return cast<ObjFile<ELF64BE>>(file)->getObj().getHeader()->e_flags;
|
|
|
|
return cast<ObjFile<ELF64LE>>(file)->getObj().getHeader()->e_flags;
|
2018-03-20 01:40:14 +08:00
|
|
|
}
|
|
|
|
|
2018-07-06 00:58:42 +08:00
|
|
|
// This file implements v2 ABI. This function makes sure that all
|
|
|
|
// object files have v2 or an unspecified version as an ABI version.
|
2018-03-20 01:40:14 +08:00
|
|
|
uint32_t PPC64::calcEFlags() const {
|
2018-07-06 01:14:33 +08:00
|
|
|
for (InputFile *f : objectFiles) {
|
2018-05-04 23:09:49 +08:00
|
|
|
uint32_t flag = getEFlags(f);
|
2018-07-06 00:58:42 +08:00
|
|
|
if (flag == 1)
|
|
|
|
error(toString(f) + ": ABI version 1 is not supported");
|
|
|
|
else if (flag > 2)
|
|
|
|
error(toString(f) + ": unrecognized e_flags: " + Twine(flag));
|
2018-05-04 23:09:49 +08:00
|
|
|
}
|
|
|
|
return 2;
|
2018-03-20 01:40:14 +08:00
|
|
|
}
|
|
|
|
|
2020-01-23 11:42:54 +08:00
|
|
|
void PPC64::relaxGot(uint8_t *loc, const Relocation &rel, uint64_t val) const {
|
|
|
|
switch (rel.type) {
|
[PPC64] toc-indirect to toc-relative relaxation
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
2019-05-07 12:26:05 +08:00
|
|
|
case R_PPC64_TOC16_HA:
|
|
|
|
// Convert "addis reg, 2, .LC0@toc@h" to "addis reg, 2, var@toc@h" or "nop".
|
2020-01-23 13:39:16 +08:00
|
|
|
relocate(loc, rel, val);
|
[PPC64] toc-indirect to toc-relative relaxation
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
2019-05-07 12:26:05 +08:00
|
|
|
break;
|
|
|
|
case R_PPC64_TOC16_LO_DS: {
|
|
|
|
// Convert "ld reg, .LC0@toc@l(reg)" to "addi reg, reg, var@toc@l" or
|
|
|
|
// "addi reg, 2, var@toc".
|
2019-06-12 14:00:39 +08:00
|
|
|
uint32_t insn = readFromHalf16(loc);
|
|
|
|
if (getPrimaryOpCode(insn) != LD)
|
[PPC64] toc-indirect to toc-relative relaxation
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
2019-05-07 12:26:05 +08:00
|
|
|
error("expected a 'ld' for got-indirect to toc-relative relaxing");
|
2019-06-12 14:00:39 +08:00
|
|
|
writeFromHalf16(loc, (insn & 0x03ffffff) | 0x38000000);
|
2020-01-23 13:39:16 +08:00
|
|
|
relocateNoSym(loc, R_PPC64_TOC16_LO, val);
|
[PPC64] toc-indirect to toc-relative relaxation
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
2019-05-07 12:26:05 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
llvm_unreachable("unexpected relocation type");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-01-23 11:42:54 +08:00
|
|
|
void PPC64::relaxTlsGdToLe(uint8_t *loc, const Relocation &rel,
|
|
|
|
uint64_t val) const {
|
2018-06-27 21:27:29 +08:00
|
|
|
// Reference: 3.7.4.2 of the 64-bit ELF V2 abi supplement.
|
|
|
|
// The general dynamic code sequence for a global `x` will look like:
|
|
|
|
// Instruction Relocation Symbol
|
|
|
|
// addis r3, r2, x@got@tlsgd@ha R_PPC64_GOT_TLSGD16_HA x
|
|
|
|
// addi r3, r3, x@got@tlsgd@l R_PPC64_GOT_TLSGD16_LO x
|
|
|
|
// bl __tls_get_addr(x@tlsgd) R_PPC64_TLSGD x
|
|
|
|
// R_PPC64_REL24 __tls_get_addr
|
|
|
|
// nop None None
|
|
|
|
|
|
|
|
// Relaxing to local exec entails converting:
|
|
|
|
// addis r3, r2, x@got@tlsgd@ha into nop
|
|
|
|
// addi r3, r3, x@got@tlsgd@l into addis r3, r13, x@tprel@ha
|
|
|
|
// bl __tls_get_addr(x@tlsgd) into nop
|
|
|
|
// nop into addi r3, r3, x@tprel@l
|
|
|
|
|
2020-01-23 11:42:54 +08:00
|
|
|
switch (rel.type) {
|
2018-06-27 21:27:29 +08:00
|
|
|
case R_PPC64_GOT_TLSGD16_HA:
|
2019-06-12 14:00:39 +08:00
|
|
|
writeFromHalf16(loc, 0x60000000); // nop
|
2018-06-27 21:27:29 +08:00
|
|
|
break;
|
2018-09-18 04:27:02 +08:00
|
|
|
case R_PPC64_GOT_TLSGD16:
|
2018-06-27 21:27:29 +08:00
|
|
|
case R_PPC64_GOT_TLSGD16_LO:
|
2019-06-12 14:00:39 +08:00
|
|
|
writeFromHalf16(loc, 0x3c6d0000); // addis r3, r13
|
2020-01-23 13:39:16 +08:00
|
|
|
relocateNoSym(loc, R_PPC64_TPREL16_HA, val);
|
2018-06-27 21:27:29 +08:00
|
|
|
break;
|
|
|
|
case R_PPC64_TLSGD:
|
|
|
|
write32(loc, 0x60000000); // nop
|
|
|
|
write32(loc + 4, 0x38630000); // addi r3, r3
|
2018-09-18 04:27:00 +08:00
|
|
|
// Since we are relocating a half16 type relocation and Loc + 4 points to
|
|
|
|
// the start of an instruction we need to advance the buffer by an extra
|
|
|
|
// 2 bytes on BE.
|
2020-01-23 13:39:16 +08:00
|
|
|
relocateNoSym(loc + 4 + (config->ekind == ELF64BEKind ? 2 : 0),
|
|
|
|
R_PPC64_TPREL16_LO, val);
|
2018-06-27 21:27:29 +08:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
llvm_unreachable("unsupported relocation for TLS GD to LE relaxation");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-01-23 11:42:54 +08:00
|
|
|
void PPC64::relaxTlsLdToLe(uint8_t *loc, const Relocation &rel,
|
|
|
|
uint64_t val) const {
|
2018-07-10 00:35:51 +08:00
|
|
|
// Reference: 3.7.4.3 of the 64-bit ELF V2 abi supplement.
|
|
|
|
// The local dynamic code sequence for a global `x` will look like:
|
|
|
|
// Instruction Relocation Symbol
|
|
|
|
// addis r3, r2, x@got@tlsld@ha R_PPC64_GOT_TLSLD16_HA x
|
|
|
|
// addi r3, r3, x@got@tlsld@l R_PPC64_GOT_TLSLD16_LO x
|
|
|
|
// bl __tls_get_addr(x@tlsgd) R_PPC64_TLSLD x
|
|
|
|
// R_PPC64_REL24 __tls_get_addr
|
|
|
|
// nop None None
|
|
|
|
|
|
|
|
// Relaxing to local exec entails converting:
|
|
|
|
// addis r3, r2, x@got@tlsld@ha into nop
|
|
|
|
// addi r3, r3, x@got@tlsld@l into addis r3, r13, 0
|
|
|
|
// bl __tls_get_addr(x@tlsgd) into nop
|
|
|
|
// nop into addi r3, r3, 4096
|
|
|
|
|
2020-01-23 11:42:54 +08:00
|
|
|
switch (rel.type) {
|
2018-07-10 00:35:51 +08:00
|
|
|
case R_PPC64_GOT_TLSLD16_HA:
|
2019-06-12 14:00:39 +08:00
|
|
|
writeFromHalf16(loc, 0x60000000); // nop
|
2018-07-10 00:35:51 +08:00
|
|
|
break;
|
|
|
|
case R_PPC64_GOT_TLSLD16_LO:
|
2019-06-12 14:00:39 +08:00
|
|
|
writeFromHalf16(loc, 0x3c6d0000); // addis r3, r13, 0
|
2018-07-10 00:35:51 +08:00
|
|
|
break;
|
|
|
|
case R_PPC64_TLSLD:
|
|
|
|
write32(loc, 0x60000000); // nop
|
|
|
|
write32(loc + 4, 0x38631000); // addi r3, r3, 4096
|
|
|
|
break;
|
|
|
|
case R_PPC64_DTPREL16:
|
|
|
|
case R_PPC64_DTPREL16_HA:
|
|
|
|
case R_PPC64_DTPREL16_HI:
|
|
|
|
case R_PPC64_DTPREL16_DS:
|
|
|
|
case R_PPC64_DTPREL16_LO:
|
|
|
|
case R_PPC64_DTPREL16_LO_DS:
|
2020-01-23 13:39:16 +08:00
|
|
|
relocate(loc, rel, val);
|
2018-07-10 00:35:51 +08:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
llvm_unreachable("unsupported relocation for TLS LD to LE relaxation");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-10-07 16:31:18 +08:00
|
|
|
unsigned getPPCDFormOp(unsigned secondaryOp) {
|
2018-08-21 23:13:53 +08:00
|
|
|
switch (secondaryOp) {
|
|
|
|
case LBZX:
|
|
|
|
return LBZ;
|
|
|
|
case LHZX:
|
|
|
|
return LHZ;
|
|
|
|
case LWZX:
|
|
|
|
return LWZ;
|
|
|
|
case LDX:
|
|
|
|
return LD;
|
|
|
|
case STBX:
|
|
|
|
return STB;
|
|
|
|
case STHX:
|
|
|
|
return STH;
|
|
|
|
case STWX:
|
|
|
|
return STW;
|
|
|
|
case STDX:
|
|
|
|
return STD;
|
|
|
|
case ADD:
|
|
|
|
return ADDI;
|
|
|
|
default:
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-01-23 11:42:54 +08:00
|
|
|
void PPC64::relaxTlsIeToLe(uint8_t *loc, const Relocation &rel,
|
|
|
|
uint64_t val) const {
|
2018-08-21 23:13:53 +08:00
|
|
|
// The initial exec code sequence for a global `x` will look like:
|
|
|
|
// Instruction Relocation Symbol
|
|
|
|
// addis r9, r2, x@got@tprel@ha R_PPC64_GOT_TPREL16_HA x
|
|
|
|
// ld r9, x@got@tprel@l(r9) R_PPC64_GOT_TPREL16_LO_DS x
|
|
|
|
// add r9, r9, x@tls R_PPC64_TLS x
|
|
|
|
|
|
|
|
// Relaxing to local exec entails converting:
|
|
|
|
// addis r9, r2, x@got@tprel@ha into nop
|
|
|
|
// ld r9, x@got@tprel@l(r9) into addis r9, r13, x@tprel@ha
|
|
|
|
// add r9, r9, x@tls into addi r9, r9, x@tprel@l
|
|
|
|
|
|
|
|
// x@tls R_PPC64_TLS is a relocation which does not compute anything,
|
|
|
|
// it is replaced with r13 (thread pointer).
|
|
|
|
|
|
|
|
// The add instruction in the initial exec sequence has multiple variations
|
|
|
|
// that need to be handled. If we are building an address it will use an add
|
|
|
|
// instruction, if we are accessing memory it will use any of the X-form
|
|
|
|
// indexed load or store instructions.
|
|
|
|
|
|
|
|
unsigned offset = (config->ekind == ELF64BEKind) ? 2 : 0;
|
2020-01-23 11:42:54 +08:00
|
|
|
switch (rel.type) {
|
2018-08-21 23:13:53 +08:00
|
|
|
case R_PPC64_GOT_TPREL16_HA:
|
|
|
|
write32(loc - offset, 0x60000000); // nop
|
|
|
|
break;
|
|
|
|
case R_PPC64_GOT_TPREL16_LO_DS:
|
|
|
|
case R_PPC64_GOT_TPREL16_DS: {
|
|
|
|
uint32_t regNo = read32(loc - offset) & 0x03E00000; // bits 6-10
|
|
|
|
write32(loc - offset, 0x3C0D0000 | regNo); // addis RegNo, r13
|
2020-01-23 13:39:16 +08:00
|
|
|
relocateNoSym(loc, R_PPC64_TPREL16_HA, val);
|
2018-08-21 23:13:53 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case R_PPC64_TLS: {
|
2018-08-28 23:16:01 +08:00
|
|
|
uint32_t primaryOp = getPrimaryOpCode(read32(loc));
|
2018-08-21 23:13:53 +08:00
|
|
|
if (primaryOp != 31)
|
|
|
|
error("unrecognized instruction for IE to LE R_PPC64_TLS");
|
|
|
|
uint32_t secondaryOp = (read32(loc) & 0x000007FE) >> 1; // bits 21-30
|
2019-06-07 01:03:10 +08:00
|
|
|
uint32_t dFormOp = getPPCDFormOp(secondaryOp);
|
|
|
|
if (dFormOp == 0)
|
|
|
|
error("unrecognized instruction for IE to LE R_PPC64_TLS");
|
2018-08-21 23:13:53 +08:00
|
|
|
write32(loc, ((dFormOp << 26) | (read32(loc) & 0x03FFFFFF)));
|
2020-01-23 13:39:16 +08:00
|
|
|
relocateNoSym(loc + offset, R_PPC64_TPREL16_LO, val);
|
2018-08-21 23:13:53 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
llvm_unreachable("unknown relocation for IE to LE");
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-11-04 05:21:47 +08:00
|
|
|
RelExpr PPC64::getRelExpr(RelType type, const Symbol &s,
|
2017-10-12 11:14:06 +08:00
|
|
|
const uint8_t *loc) const {
|
2017-06-17 01:32:43 +08:00
|
|
|
switch (type) {
|
2019-08-15 13:22:23 +08:00
|
|
|
case R_PPC64_NONE:
|
|
|
|
return R_NONE;
|
|
|
|
case R_PPC64_ADDR16:
|
|
|
|
case R_PPC64_ADDR16_DS:
|
|
|
|
case R_PPC64_ADDR16_HA:
|
|
|
|
case R_PPC64_ADDR16_HI:
|
|
|
|
case R_PPC64_ADDR16_HIGHER:
|
|
|
|
case R_PPC64_ADDR16_HIGHERA:
|
|
|
|
case R_PPC64_ADDR16_HIGHEST:
|
|
|
|
case R_PPC64_ADDR16_HIGHESTA:
|
|
|
|
case R_PPC64_ADDR16_LO:
|
|
|
|
case R_PPC64_ADDR16_LO_DS:
|
|
|
|
case R_PPC64_ADDR32:
|
|
|
|
case R_PPC64_ADDR64:
|
|
|
|
return R_ABS;
|
2018-12-19 01:34:26 +08:00
|
|
|
case R_PPC64_GOT16:
|
|
|
|
case R_PPC64_GOT16_DS:
|
|
|
|
case R_PPC64_GOT16_HA:
|
|
|
|
case R_PPC64_GOT16_HI:
|
|
|
|
case R_PPC64_GOT16_LO:
|
|
|
|
case R_PPC64_GOT16_LO_DS:
|
|
|
|
return R_GOT_OFF;
|
2017-06-17 01:32:43 +08:00
|
|
|
case R_PPC64_TOC16:
|
|
|
|
case R_PPC64_TOC16_DS:
|
|
|
|
case R_PPC64_TOC16_HI:
|
|
|
|
case R_PPC64_TOC16_LO:
|
|
|
|
return R_GOTREL;
|
[PPC64] toc-indirect to toc-relative relaxation
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
2019-05-07 12:26:05 +08:00
|
|
|
case R_PPC64_TOC16_HA:
|
|
|
|
case R_PPC64_TOC16_LO_DS:
|
|
|
|
return config->tocOptimize ? R_PPC64_RELAX_TOC : R_GOTREL;
|
2017-06-17 01:32:43 +08:00
|
|
|
case R_PPC64_TOC:
|
2019-06-03 14:21:33 +08:00
|
|
|
return R_PPC64_TOCBASE;
|
2018-12-04 20:26:21 +08:00
|
|
|
case R_PPC64_REL14:
|
2017-06-17 01:32:43 +08:00
|
|
|
case R_PPC64_REL24:
|
2019-06-03 14:21:33 +08:00
|
|
|
return R_PPC64_CALL_PLT;
|
2018-03-21 23:04:04 +08:00
|
|
|
case R_PPC64_REL16_LO:
|
|
|
|
case R_PPC64_REL16_HA:
|
2019-08-17 14:28:03 +08:00
|
|
|
case R_PPC64_REL16_HI:
|
2018-05-14 23:26:44 +08:00
|
|
|
case R_PPC64_REL32:
|
2018-05-15 00:39:45 +08:00
|
|
|
case R_PPC64_REL64:
|
2018-03-21 23:04:04 +08:00
|
|
|
return R_PC;
|
2018-05-29 22:34:38 +08:00
|
|
|
case R_PPC64_GOT_TLSGD16:
|
|
|
|
case R_PPC64_GOT_TLSGD16_HA:
|
|
|
|
case R_PPC64_GOT_TLSGD16_HI:
|
|
|
|
case R_PPC64_GOT_TLSGD16_LO:
|
|
|
|
return R_TLSGD_GOT;
|
2018-06-01 02:44:12 +08:00
|
|
|
case R_PPC64_GOT_TLSLD16:
|
|
|
|
case R_PPC64_GOT_TLSLD16_HA:
|
|
|
|
case R_PPC64_GOT_TLSLD16_HI:
|
|
|
|
case R_PPC64_GOT_TLSLD16_LO:
|
|
|
|
return R_TLSLD_GOT;
|
2018-06-01 23:20:56 +08:00
|
|
|
case R_PPC64_GOT_TPREL16_HA:
|
|
|
|
case R_PPC64_GOT_TPREL16_LO_DS:
|
|
|
|
case R_PPC64_GOT_TPREL16_DS:
|
|
|
|
case R_PPC64_GOT_TPREL16_HI:
|
|
|
|
return R_GOT_OFF;
|
2018-06-27 21:55:41 +08:00
|
|
|
case R_PPC64_GOT_DTPREL16_HA:
|
|
|
|
case R_PPC64_GOT_DTPREL16_LO_DS:
|
|
|
|
case R_PPC64_GOT_DTPREL16_DS:
|
|
|
|
case R_PPC64_GOT_DTPREL16_HI:
|
|
|
|
return R_TLSLD_GOT_OFF;
|
2018-06-09 01:04:09 +08:00
|
|
|
case R_PPC64_TPREL16:
|
|
|
|
case R_PPC64_TPREL16_HA:
|
|
|
|
case R_PPC64_TPREL16_LO:
|
|
|
|
case R_PPC64_TPREL16_HI:
|
|
|
|
case R_PPC64_TPREL16_DS:
|
|
|
|
case R_PPC64_TPREL16_LO_DS:
|
|
|
|
case R_PPC64_TPREL16_HIGHER:
|
|
|
|
case R_PPC64_TPREL16_HIGHERA:
|
|
|
|
case R_PPC64_TPREL16_HIGHEST:
|
|
|
|
case R_PPC64_TPREL16_HIGHESTA:
|
|
|
|
return R_TLS;
|
2018-06-12 09:47:02 +08:00
|
|
|
case R_PPC64_DTPREL16:
|
|
|
|
case R_PPC64_DTPREL16_DS:
|
|
|
|
case R_PPC64_DTPREL16_HA:
|
|
|
|
case R_PPC64_DTPREL16_HI:
|
|
|
|
case R_PPC64_DTPREL16_HIGHER:
|
|
|
|
case R_PPC64_DTPREL16_HIGHERA:
|
|
|
|
case R_PPC64_DTPREL16_HIGHEST:
|
|
|
|
case R_PPC64_DTPREL16_HIGHESTA:
|
|
|
|
case R_PPC64_DTPREL16_LO:
|
|
|
|
case R_PPC64_DTPREL16_LO_DS:
|
2018-06-13 04:26:49 +08:00
|
|
|
case R_PPC64_DTPREL64:
|
2019-04-23 14:31:44 +08:00
|
|
|
return R_DTPREL;
|
2018-05-29 22:34:38 +08:00
|
|
|
case R_PPC64_TLSGD:
|
[PPC64] Thread-local storage general-dynamic to initial-exec relaxation.
Patch adds support for relaxing the general-dynamic tls sequence to
initial-exec.
the relaxation performs the following transformation:
addis r3, r2, x@got@tlsgd@ha --> addis r3, r2, x@got@tprel@ha
addi r3, r3, x@got@tlsgd@l --> ld r3, x@got@tprel@l(r3)
bl __tls_get_addr(x@tlsgd) --> nop
nop --> add r3, r3, r13
and instead of emitting a DTPMOD64/DTPREL64 pair for x, we emit a single
R_PPC64_TPREL64.
Differential Revision: https://reviews.llvm.org/D48090
llvm-svn: 335651
2018-06-27 03:38:18 +08:00
|
|
|
return R_TLSDESC_CALL;
|
2018-06-01 02:44:12 +08:00
|
|
|
case R_PPC64_TLSLD:
|
2018-07-10 00:35:51 +08:00
|
|
|
return R_TLSLD_HINT;
|
2018-06-01 23:20:56 +08:00
|
|
|
case R_PPC64_TLS:
|
2018-08-21 23:13:53 +08:00
|
|
|
return R_TLSIE_HINT;
|
2017-10-12 11:14:06 +08:00
|
|
|
default:
|
2019-08-15 13:22:23 +08:00
|
|
|
error(getErrorLocation(loc) + "unknown relocation (" + Twine(type) +
|
|
|
|
") against symbol " + toString(s));
|
|
|
|
return R_NONE;
|
2017-06-17 01:32:43 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[ELF][ARM][AARCH64][MIPS][PPC] Simplify the logic to create R_*_RELATIVE for 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
2019-06-20 22:00:08 +08:00
|
|
|
RelType PPC64::getDynRel(RelType type) const {
|
|
|
|
if (type == R_PPC64_ADDR64 || type == R_PPC64_TOC)
|
|
|
|
return R_PPC64_ADDR64;
|
|
|
|
return R_PPC64_NONE;
|
|
|
|
}
|
|
|
|
|
2018-03-20 01:40:14 +08:00
|
|
|
void PPC64::writeGotHeader(uint8_t *buf) const {
|
2018-05-04 23:09:49 +08:00
|
|
|
write64(buf, getPPC64TocBase());
|
2018-03-20 01:40:14 +08:00
|
|
|
}
|
|
|
|
|
2018-05-09 10:07:53 +08:00
|
|
|
void PPC64::writePltHeader(uint8_t *buf) const {
|
|
|
|
// The generic resolver stub goes first.
|
|
|
|
write32(buf + 0, 0x7c0802a6); // mflr r0
|
|
|
|
write32(buf + 4, 0x429f0005); // bcl 20,4*cr7+so,8 <_glink+0x8>
|
|
|
|
write32(buf + 8, 0x7d6802a6); // mflr r11
|
|
|
|
write32(buf + 12, 0x7c0803a6); // mtlr r0
|
|
|
|
write32(buf + 16, 0x7d8b6050); // subf r12, r11, r12
|
|
|
|
write32(buf + 20, 0x380cffcc); // subi r0,r12,52
|
|
|
|
write32(buf + 24, 0x7800f082); // srdi r0,r0,62,2
|
|
|
|
write32(buf + 28, 0xe98b002c); // ld r12,44(r11)
|
|
|
|
write32(buf + 32, 0x7d6c5a14); // add r11,r12,r11
|
|
|
|
write32(buf + 36, 0xe98b0000); // ld r12,0(r11)
|
|
|
|
write32(buf + 40, 0xe96b0008); // ld r11,8(r11)
|
|
|
|
write32(buf + 44, 0x7d8903a6); // mtctr r12
|
|
|
|
write32(buf + 48, 0x4e800420); // bctr
|
|
|
|
|
|
|
|
// The 'bcl' instruction will set the link register to the address of the
|
|
|
|
// following instruction ('mflr r11'). Here we store the offset from that
|
|
|
|
// instruction to the first entry in the GotPlt section.
|
2018-09-26 03:26:58 +08:00
|
|
|
int64_t gotPltOffset = in.gotPlt->getVA() - (in.plt->getVA() + 8);
|
2018-05-09 10:07:53 +08:00
|
|
|
write64(buf + 52, gotPltOffset);
|
|
|
|
}
|
|
|
|
|
2019-12-18 05:43:04 +08:00
|
|
|
void PPC64::writePlt(uint8_t *buf, const Symbol &sym,
|
|
|
|
uint64_t /*pltEntryAddr*/) const {
|
|
|
|
int32_t offset = pltHeaderSize + sym.pltIndex * pltEntrySize;
|
2018-10-23 02:20:18 +08:00
|
|
|
// bl __glink_PLTresolve
|
|
|
|
write32(buf, 0x48000000 | ((-offset) & 0x03FFFFFc));
|
2018-05-09 10:07:53 +08:00
|
|
|
}
|
|
|
|
|
[ELF][PPC64] Implement IPLT code sequence for non-preemptible IFUNC
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
2019-12-14 10:30:21 +08:00
|
|
|
void PPC64::writeIplt(uint8_t *buf, const Symbol &sym,
|
|
|
|
uint64_t /*pltEntryAddr*/) const {
|
|
|
|
writePPC64LoadAndBranch(buf, sym.getGotPltVA() - getPPC64TocBase());
|
|
|
|
}
|
|
|
|
|
2017-10-12 06:49:24 +08:00
|
|
|
static std::pair<RelType, uint64_t> toAddr16Rel(RelType type, uint64_t val) {
|
2018-06-12 09:47:02 +08:00
|
|
|
// Relocations relative to the toc-base need to be adjusted by the Toc offset.
|
|
|
|
uint64_t tocBiasedVal = val - ppc64TocOffset;
|
|
|
|
// Relocations relative to dtv[dtpmod] need to be adjusted by the DTP offset.
|
|
|
|
uint64_t dtpBiasedVal = val - dynamicThreadPointerOffset;
|
|
|
|
|
2017-06-17 01:32:43 +08:00
|
|
|
switch (type) {
|
2018-06-12 09:47:02 +08:00
|
|
|
// TOC biased relocation.
|
2018-12-19 01:34:26 +08:00
|
|
|
case R_PPC64_GOT16:
|
2018-05-29 22:34:38 +08:00
|
|
|
case R_PPC64_GOT_TLSGD16:
|
2018-06-01 02:44:12 +08:00
|
|
|
case R_PPC64_GOT_TLSLD16:
|
2017-06-17 01:32:43 +08:00
|
|
|
case R_PPC64_TOC16:
|
2018-06-12 09:47:02 +08:00
|
|
|
return {R_PPC64_ADDR16, tocBiasedVal};
|
2018-12-19 01:34:26 +08:00
|
|
|
case R_PPC64_GOT16_DS:
|
2017-06-17 01:32:43 +08:00
|
|
|
case R_PPC64_TOC16_DS:
|
2018-06-01 23:20:56 +08:00
|
|
|
case R_PPC64_GOT_TPREL16_DS:
|
2018-06-27 21:55:41 +08:00
|
|
|
case R_PPC64_GOT_DTPREL16_DS:
|
2018-06-12 09:47:02 +08:00
|
|
|
return {R_PPC64_ADDR16_DS, tocBiasedVal};
|
2018-12-19 01:34:26 +08:00
|
|
|
case R_PPC64_GOT16_HA:
|
2018-05-29 22:34:38 +08:00
|
|
|
case R_PPC64_GOT_TLSGD16_HA:
|
2018-06-01 02:44:12 +08:00
|
|
|
case R_PPC64_GOT_TLSLD16_HA:
|
2018-06-01 23:20:56 +08:00
|
|
|
case R_PPC64_GOT_TPREL16_HA:
|
2018-06-27 21:55:41 +08:00
|
|
|
case R_PPC64_GOT_DTPREL16_HA:
|
2017-06-17 01:32:43 +08:00
|
|
|
case R_PPC64_TOC16_HA:
|
2018-06-12 09:47:02 +08:00
|
|
|
return {R_PPC64_ADDR16_HA, tocBiasedVal};
|
2018-12-19 01:34:26 +08:00
|
|
|
case R_PPC64_GOT16_HI:
|
2018-05-29 22:34:38 +08:00
|
|
|
case R_PPC64_GOT_TLSGD16_HI:
|
2018-06-01 02:44:12 +08:00
|
|
|
case R_PPC64_GOT_TLSLD16_HI:
|
2018-06-01 23:20:56 +08:00
|
|
|
case R_PPC64_GOT_TPREL16_HI:
|
2018-06-27 21:55:41 +08:00
|
|
|
case R_PPC64_GOT_DTPREL16_HI:
|
2017-06-17 01:32:43 +08:00
|
|
|
case R_PPC64_TOC16_HI:
|
2018-06-12 09:47:02 +08:00
|
|
|
return {R_PPC64_ADDR16_HI, tocBiasedVal};
|
2018-12-19 01:34:26 +08:00
|
|
|
case R_PPC64_GOT16_LO:
|
2018-05-29 22:34:38 +08:00
|
|
|
case R_PPC64_GOT_TLSGD16_LO:
|
2018-06-01 02:44:12 +08:00
|
|
|
case R_PPC64_GOT_TLSLD16_LO:
|
2017-06-17 01:32:43 +08:00
|
|
|
case R_PPC64_TOC16_LO:
|
2018-06-12 09:47:02 +08:00
|
|
|
return {R_PPC64_ADDR16_LO, tocBiasedVal};
|
2018-12-19 01:34:26 +08:00
|
|
|
case R_PPC64_GOT16_LO_DS:
|
2017-06-17 01:32:43 +08:00
|
|
|
case R_PPC64_TOC16_LO_DS:
|
2018-06-01 23:20:56 +08:00
|
|
|
case R_PPC64_GOT_TPREL16_LO_DS:
|
2018-06-27 21:55:41 +08:00
|
|
|
case R_PPC64_GOT_DTPREL16_LO_DS:
|
2018-06-12 09:47:02 +08:00
|
|
|
return {R_PPC64_ADDR16_LO_DS, tocBiasedVal};
|
|
|
|
|
|
|
|
// Dynamic Thread pointer biased relocation types.
|
|
|
|
case R_PPC64_DTPREL16:
|
|
|
|
return {R_PPC64_ADDR16, dtpBiasedVal};
|
|
|
|
case R_PPC64_DTPREL16_DS:
|
|
|
|
return {R_PPC64_ADDR16_DS, dtpBiasedVal};
|
|
|
|
case R_PPC64_DTPREL16_HA:
|
|
|
|
return {R_PPC64_ADDR16_HA, dtpBiasedVal};
|
|
|
|
case R_PPC64_DTPREL16_HI:
|
|
|
|
return {R_PPC64_ADDR16_HI, dtpBiasedVal};
|
|
|
|
case R_PPC64_DTPREL16_HIGHER:
|
|
|
|
return {R_PPC64_ADDR16_HIGHER, dtpBiasedVal};
|
|
|
|
case R_PPC64_DTPREL16_HIGHERA:
|
|
|
|
return {R_PPC64_ADDR16_HIGHERA, dtpBiasedVal};
|
|
|
|
case R_PPC64_DTPREL16_HIGHEST:
|
|
|
|
return {R_PPC64_ADDR16_HIGHEST, dtpBiasedVal};
|
|
|
|
case R_PPC64_DTPREL16_HIGHESTA:
|
|
|
|
return {R_PPC64_ADDR16_HIGHESTA, dtpBiasedVal};
|
|
|
|
case R_PPC64_DTPREL16_LO:
|
|
|
|
return {R_PPC64_ADDR16_LO, dtpBiasedVal};
|
|
|
|
case R_PPC64_DTPREL16_LO_DS:
|
|
|
|
return {R_PPC64_ADDR16_LO_DS, dtpBiasedVal};
|
2018-06-13 04:26:49 +08:00
|
|
|
case R_PPC64_DTPREL64:
|
|
|
|
return {R_PPC64_ADDR64, dtpBiasedVal};
|
2018-06-12 09:47:02 +08:00
|
|
|
|
2017-06-17 01:32:43 +08:00
|
|
|
default:
|
|
|
|
return {type, val};
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-12-21 01:00:33 +08:00
|
|
|
static bool isTocOptType(RelType type) {
|
|
|
|
switch (type) {
|
|
|
|
case R_PPC64_GOT16_HA:
|
|
|
|
case R_PPC64_GOT16_LO_DS:
|
|
|
|
case R_PPC64_TOC16_HA:
|
|
|
|
case R_PPC64_TOC16_LO_DS:
|
|
|
|
case R_PPC64_TOC16_LO:
|
|
|
|
return true;
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
2018-09-20 08:26:44 +08:00
|
|
|
}
|
|
|
|
|
2020-01-23 13:39:16 +08:00
|
|
|
void PPC64::relocate(uint8_t *loc, const Relocation &rel, uint64_t val) const {
|
|
|
|
RelType type = rel.type;
|
2018-12-21 01:00:33 +08:00
|
|
|
bool shouldTocOptimize = isTocOptType(type);
|
2019-01-10 23:08:02 +08:00
|
|
|
// For dynamic thread pointer relative, toc-relative, and got-indirect
|
|
|
|
// relocations, proceed in terms of the corresponding ADDR16 relocation type.
|
2017-06-17 01:32:43 +08:00
|
|
|
std::tie(type, val) = toAddr16Rel(type, val);
|
|
|
|
|
|
|
|
switch (type) {
|
|
|
|
case R_PPC64_ADDR14: {
|
2020-01-23 13:39:16 +08:00
|
|
|
checkAlignment(loc, val, 4, rel);
|
2017-06-17 01:32:43 +08:00
|
|
|
// Preserve the AA/LK bits in the branch instruction
|
|
|
|
uint8_t aalk = loc[3];
|
2018-03-10 02:03:22 +08:00
|
|
|
write16(loc + 2, (aalk & 3) | (val & 0xfffc));
|
2017-06-17 01:32:43 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case R_PPC64_ADDR16:
|
2020-01-23 13:39:16 +08:00
|
|
|
checkIntUInt(loc, val, 16, rel);
|
2018-03-10 02:03:22 +08:00
|
|
|
write16(loc, val);
|
2017-06-17 01:32:43 +08:00
|
|
|
break;
|
[ELF][PPC][X86] Use [-2**(n-1), 2**n) to check overflows for R_PPC_ADDR16, R_PPC64_ADDR{16,32}, R_X86_64_{8,16}
Similar to R_AARCH64_ABS32, R_PPC64_ADDR32 can represent either a signed
value or unsigned value, thus we should use `[-2**(n-1), 2**n)` instead of
`[-2**(n-1), 2**(n-1))` to check overflows.
The issue manifests as a bogus linker error when linking the powerpc64le Linux kernel.
The new behavior is compatible with ld.bfd's complain_overflow_bitfield.
The upper bound of the error message is not correct. Fix it as well.
The changes to R_PPC_ADDR16, R_PPC64_ADDR16, R_X86_64_8 and R_X86_64_16 are similar.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D63690
llvm-svn: 364164
2019-06-24 13:37:20 +08:00
|
|
|
case R_PPC64_ADDR32:
|
2020-01-23 13:39:16 +08:00
|
|
|
checkIntUInt(loc, val, 32, rel);
|
[ELF][PPC][X86] Use [-2**(n-1), 2**n) to check overflows for R_PPC_ADDR16, R_PPC64_ADDR{16,32}, R_X86_64_{8,16}
Similar to R_AARCH64_ABS32, R_PPC64_ADDR32 can represent either a signed
value or unsigned value, thus we should use `[-2**(n-1), 2**n)` instead of
`[-2**(n-1), 2**(n-1))` to check overflows.
The issue manifests as a bogus linker error when linking the powerpc64le Linux kernel.
The new behavior is compatible with ld.bfd's complain_overflow_bitfield.
The upper bound of the error message is not correct. Fix it as well.
The changes to R_PPC_ADDR16, R_PPC64_ADDR16, R_X86_64_8 and R_X86_64_16 are similar.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D63690
llvm-svn: 364164
2019-06-24 13:37:20 +08:00
|
|
|
write32(loc, val);
|
|
|
|
break;
|
2017-06-17 01:32:43 +08:00
|
|
|
case R_PPC64_ADDR16_DS:
|
2018-08-28 23:16:01 +08:00
|
|
|
case R_PPC64_TPREL16_DS: {
|
2020-01-23 13:39:16 +08:00
|
|
|
checkInt(loc, val, 16, rel);
|
2018-08-28 23:16:01 +08:00
|
|
|
// DQ-form instructions use bits 28-31 as part of the instruction encoding
|
|
|
|
// DS-form instructions only use bits 30-31.
|
2019-06-12 14:00:39 +08:00
|
|
|
uint16_t mask = isDQFormInstruction(readFromHalf16(loc)) ? 0xf : 0x3;
|
2020-01-23 13:39:16 +08:00
|
|
|
checkAlignment(loc, lo(val), mask + 1, rel);
|
2018-08-28 23:16:01 +08:00
|
|
|
write16(loc, (read16(loc) & mask) | lo(val));
|
|
|
|
} break;
|
2017-06-17 01:32:43 +08:00
|
|
|
case R_PPC64_ADDR16_HA:
|
|
|
|
case R_PPC64_REL16_HA:
|
2018-06-09 01:04:09 +08:00
|
|
|
case R_PPC64_TPREL16_HA:
|
2018-12-21 01:00:33 +08:00
|
|
|
if (config->tocOptimize && shouldTocOptimize && ha(val) == 0)
|
2019-06-12 14:00:39 +08:00
|
|
|
writeFromHalf16(loc, 0x60000000);
|
2018-09-20 08:26:44 +08:00
|
|
|
else
|
|
|
|
write16(loc, ha(val));
|
2017-06-17 01:32:43 +08:00
|
|
|
break;
|
|
|
|
case R_PPC64_ADDR16_HI:
|
|
|
|
case R_PPC64_REL16_HI:
|
2018-06-09 01:04:09 +08:00
|
|
|
case R_PPC64_TPREL16_HI:
|
2018-06-13 08:50:17 +08:00
|
|
|
write16(loc, hi(val));
|
2017-06-17 01:32:43 +08:00
|
|
|
break;
|
|
|
|
case R_PPC64_ADDR16_HIGHER:
|
2018-06-09 01:04:09 +08:00
|
|
|
case R_PPC64_TPREL16_HIGHER:
|
2018-06-13 08:50:17 +08:00
|
|
|
write16(loc, higher(val));
|
2017-06-17 01:32:43 +08:00
|
|
|
break;
|
|
|
|
case R_PPC64_ADDR16_HIGHERA:
|
2018-06-09 01:04:09 +08:00
|
|
|
case R_PPC64_TPREL16_HIGHERA:
|
2018-06-13 08:50:17 +08:00
|
|
|
write16(loc, highera(val));
|
2017-06-17 01:32:43 +08:00
|
|
|
break;
|
|
|
|
case R_PPC64_ADDR16_HIGHEST:
|
2018-06-09 01:04:09 +08:00
|
|
|
case R_PPC64_TPREL16_HIGHEST:
|
2018-06-13 08:50:17 +08:00
|
|
|
write16(loc, highest(val));
|
2017-06-17 01:32:43 +08:00
|
|
|
break;
|
|
|
|
case R_PPC64_ADDR16_HIGHESTA:
|
2018-06-09 01:04:09 +08:00
|
|
|
case R_PPC64_TPREL16_HIGHESTA:
|
2018-06-13 08:50:17 +08:00
|
|
|
write16(loc, highesta(val));
|
2017-06-17 01:32:43 +08:00
|
|
|
break;
|
|
|
|
case R_PPC64_ADDR16_LO:
|
2018-03-21 23:04:04 +08:00
|
|
|
case R_PPC64_REL16_LO:
|
2018-06-09 01:04:09 +08:00
|
|
|
case R_PPC64_TPREL16_LO:
|
2019-10-29 09:41:38 +08:00
|
|
|
// When the high-adjusted part of a toc relocation evaluates to 0, it is
|
2018-09-20 08:26:44 +08:00
|
|
|
// changed into a nop. The lo part then needs to be updated to use the
|
|
|
|
// toc-pointer register r2, as the base register.
|
2018-12-21 01:00:33 +08:00
|
|
|
if (config->tocOptimize && shouldTocOptimize && ha(val) == 0) {
|
2019-06-12 14:00:39 +08:00
|
|
|
uint32_t insn = readFromHalf16(loc);
|
|
|
|
if (isInstructionUpdateForm(insn))
|
2018-09-20 08:26:44 +08:00
|
|
|
error(getErrorLocation(loc) +
|
|
|
|
"can't toc-optimize an update instruction: 0x" +
|
2019-06-12 14:00:39 +08:00
|
|
|
utohexstr(insn));
|
|
|
|
writeFromHalf16(loc, (insn & 0xffe00000) | 0x00020000 | lo(val));
|
|
|
|
} else {
|
|
|
|
write16(loc, lo(val));
|
2018-09-20 08:26:44 +08:00
|
|
|
}
|
2017-06-17 01:32:43 +08:00
|
|
|
break;
|
|
|
|
case R_PPC64_ADDR16_LO_DS:
|
2018-08-28 23:16:01 +08:00
|
|
|
case R_PPC64_TPREL16_LO_DS: {
|
|
|
|
// DQ-form instructions use bits 28-31 as part of the instruction encoding
|
|
|
|
// DS-form instructions only use bits 30-31.
|
2019-06-12 14:00:39 +08:00
|
|
|
uint32_t insn = readFromHalf16(loc);
|
|
|
|
uint16_t mask = isDQFormInstruction(insn) ? 0xf : 0x3;
|
2020-01-23 13:39:16 +08:00
|
|
|
checkAlignment(loc, lo(val), mask + 1, rel);
|
2018-12-21 01:00:33 +08:00
|
|
|
if (config->tocOptimize && shouldTocOptimize && ha(val) == 0) {
|
2019-10-29 09:41:38 +08:00
|
|
|
// When the high-adjusted part of a toc relocation evaluates to 0, it is
|
2018-09-20 08:26:44 +08:00
|
|
|
// changed into a nop. The lo part then needs to be updated to use the toc
|
|
|
|
// pointer register r2, as the base register.
|
2019-06-12 14:00:39 +08:00
|
|
|
if (isInstructionUpdateForm(insn))
|
2018-09-20 08:26:44 +08:00
|
|
|
error(getErrorLocation(loc) +
|
|
|
|
"Can't toc-optimize an update instruction: 0x" +
|
2019-06-12 14:00:39 +08:00
|
|
|
Twine::utohexstr(insn));
|
|
|
|
insn &= 0xffe00000 | mask;
|
|
|
|
writeFromHalf16(loc, insn | 0x00020000 | lo(val));
|
|
|
|
} else {
|
|
|
|
write16(loc, (read16(loc) & mask) | lo(val));
|
2018-09-20 08:26:44 +08:00
|
|
|
}
|
2018-08-28 23:16:01 +08:00
|
|
|
} break;
|
[ELF][PPC][X86] Use [-2**(n-1), 2**n) to check overflows for R_PPC_ADDR16, R_PPC64_ADDR{16,32}, R_X86_64_{8,16}
Similar to R_AARCH64_ABS32, R_PPC64_ADDR32 can represent either a signed
value or unsigned value, thus we should use `[-2**(n-1), 2**n)` instead of
`[-2**(n-1), 2**(n-1))` to check overflows.
The issue manifests as a bogus linker error when linking the powerpc64le Linux kernel.
The new behavior is compatible with ld.bfd's complain_overflow_bitfield.
The upper bound of the error message is not correct. Fix it as well.
The changes to R_PPC_ADDR16, R_PPC64_ADDR16, R_X86_64_8 and R_X86_64_16 are similar.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D63690
llvm-svn: 364164
2019-06-24 13:37:20 +08:00
|
|
|
case R_PPC64_TPREL16:
|
2020-01-23 13:39:16 +08:00
|
|
|
checkInt(loc, val, 16, rel);
|
[ELF][PPC][X86] Use [-2**(n-1), 2**n) to check overflows for R_PPC_ADDR16, R_PPC64_ADDR{16,32}, R_X86_64_{8,16}
Similar to R_AARCH64_ABS32, R_PPC64_ADDR32 can represent either a signed
value or unsigned value, thus we should use `[-2**(n-1), 2**n)` instead of
`[-2**(n-1), 2**(n-1))` to check overflows.
The issue manifests as a bogus linker error when linking the powerpc64le Linux kernel.
The new behavior is compatible with ld.bfd's complain_overflow_bitfield.
The upper bound of the error message is not correct. Fix it as well.
The changes to R_PPC_ADDR16, R_PPC64_ADDR16, R_X86_64_8 and R_X86_64_16 are similar.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D63690
llvm-svn: 364164
2019-06-24 13:37:20 +08:00
|
|
|
write16(loc, val);
|
|
|
|
break;
|
2017-06-17 01:32:43 +08:00
|
|
|
case R_PPC64_REL32:
|
2020-01-23 13:39:16 +08:00
|
|
|
checkInt(loc, val, 32, rel);
|
2018-03-10 02:03:22 +08:00
|
|
|
write32(loc, val);
|
2017-06-17 01:32:43 +08:00
|
|
|
break;
|
|
|
|
case R_PPC64_ADDR64:
|
|
|
|
case R_PPC64_REL64:
|
|
|
|
case R_PPC64_TOC:
|
2018-03-10 02:03:22 +08:00
|
|
|
write64(loc, val);
|
2017-06-17 01:32:43 +08:00
|
|
|
break;
|
2018-12-04 20:26:21 +08:00
|
|
|
case R_PPC64_REL14: {
|
|
|
|
uint32_t mask = 0x0000FFFC;
|
2020-01-23 13:39:16 +08:00
|
|
|
checkInt(loc, val, 16, rel);
|
|
|
|
checkAlignment(loc, val, 4, rel);
|
2018-12-04 20:26:21 +08:00
|
|
|
write32(loc, (read32(loc) & ~mask) | (val & mask));
|
|
|
|
break;
|
|
|
|
}
|
2017-06-17 01:32:43 +08:00
|
|
|
case R_PPC64_REL24: {
|
|
|
|
uint32_t mask = 0x03FFFFFC;
|
2020-01-23 13:39:16 +08:00
|
|
|
checkInt(loc, val, 26, rel);
|
|
|
|
checkAlignment(loc, val, 4, rel);
|
2018-03-10 02:03:22 +08:00
|
|
|
write32(loc, (read32(loc) & ~mask) | (val & mask));
|
2017-06-17 01:32:43 +08:00
|
|
|
break;
|
|
|
|
}
|
2018-06-27 21:55:41 +08:00
|
|
|
case R_PPC64_DTPREL64:
|
|
|
|
write64(loc, val - dynamicThreadPointerOffset);
|
|
|
|
break;
|
2017-06-17 01:32:43 +08:00
|
|
|
default:
|
2019-08-15 13:22:23 +08:00
|
|
|
llvm_unreachable("unknown relocation");
|
2017-06-17 01:32:43 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-05-07 03:13:29 +08:00
|
|
|
bool PPC64::needsThunk(RelExpr expr, RelType type, const InputFile *file,
|
2019-12-03 06:20:42 +08:00
|
|
|
uint64_t branchAddr, const Symbol &s, int64_t a) const {
|
2018-12-04 20:26:21 +08:00
|
|
|
if (type != R_PPC64_REL14 && type != R_PPC64_REL24)
|
2018-11-15 01:56:43 +08:00
|
|
|
return false;
|
|
|
|
|
|
|
|
// If a function is in the Plt it needs to be called with a call-stub.
|
|
|
|
if (s.isInPlt())
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// If a symbol is a weak undefined and we are compiling an executable
|
|
|
|
// it doesn't need a range-extending thunk since it can't be called.
|
|
|
|
if (s.isUndefWeak() && !config->shared)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// If the offset exceeds the range of the branch type then it will need
|
|
|
|
// a range-extending thunk.
|
2019-04-24 22:03:30 +08:00
|
|
|
// See the comment in getRelocTargetVA() about R_PPC64_CALL.
|
|
|
|
return !inBranchRange(type, branchAddr,
|
2019-12-03 06:20:42 +08:00
|
|
|
s.getVA(a) +
|
2019-04-24 22:03:30 +08:00
|
|
|
getPPC64GlobalEntryToLocalEntryOffset(s.stOther));
|
2018-11-15 01:56:43 +08:00
|
|
|
}
|
|
|
|
|
2019-05-10 13:51:00 +08:00
|
|
|
uint32_t PPC64::getThunkSectionSpacing() const {
|
|
|
|
// See comment in Arch/ARM.cpp for a more detailed explanation of
|
|
|
|
// getThunkSectionSpacing(). For PPC64 we pick the constant here based on
|
|
|
|
// R_PPC64_REL24, which is used by unconditional branch instructions.
|
|
|
|
// 0x2000000 = (1 << 24-1) * 4
|
|
|
|
return 0x2000000;
|
|
|
|
}
|
|
|
|
|
2018-11-15 01:56:43 +08:00
|
|
|
bool PPC64::inBranchRange(RelType type, uint64_t src, uint64_t dst) const {
|
|
|
|
int64_t offset = dst - src;
|
2018-12-04 20:26:21 +08:00
|
|
|
if (type == R_PPC64_REL14)
|
|
|
|
return isInt<16>(offset);
|
|
|
|
if (type == R_PPC64_REL24)
|
|
|
|
return isInt<26>(offset);
|
|
|
|
llvm_unreachable("unsupported relocation type used in branch");
|
2018-05-07 03:13:29 +08:00
|
|
|
}
|
|
|
|
|
[PPC64] Thread-local storage general-dynamic to initial-exec relaxation.
Patch adds support for relaxing the general-dynamic tls sequence to
initial-exec.
the relaxation performs the following transformation:
addis r3, r2, x@got@tlsgd@ha --> addis r3, r2, x@got@tprel@ha
addi r3, r3, x@got@tlsgd@l --> ld r3, x@got@tprel@l(r3)
bl __tls_get_addr(x@tlsgd) --> nop
nop --> add r3, r3, r13
and instead of emitting a DTPMOD64/DTPREL64 pair for x, we emit a single
R_PPC64_TPREL64.
Differential Revision: https://reviews.llvm.org/D48090
llvm-svn: 335651
2018-06-27 03:38:18 +08:00
|
|
|
RelExpr PPC64::adjustRelaxExpr(RelType type, const uint8_t *data,
|
|
|
|
RelExpr expr) const {
|
|
|
|
if (expr == R_RELAX_TLS_GD_TO_IE)
|
|
|
|
return R_RELAX_TLS_GD_TO_IE_GOT_OFF;
|
2018-07-10 00:35:51 +08:00
|
|
|
if (expr == R_RELAX_TLS_LD_TO_LE)
|
|
|
|
return R_RELAX_TLS_LD_TO_LE_ABS;
|
[PPC64] Thread-local storage general-dynamic to initial-exec relaxation.
Patch adds support for relaxing the general-dynamic tls sequence to
initial-exec.
the relaxation performs the following transformation:
addis r3, r2, x@got@tlsgd@ha --> addis r3, r2, x@got@tprel@ha
addi r3, r3, x@got@tlsgd@l --> ld r3, x@got@tprel@l(r3)
bl __tls_get_addr(x@tlsgd) --> nop
nop --> add r3, r3, r13
and instead of emitting a DTPMOD64/DTPREL64 pair for x, we emit a single
R_PPC64_TPREL64.
Differential Revision: https://reviews.llvm.org/D48090
llvm-svn: 335651
2018-06-27 03:38:18 +08:00
|
|
|
return expr;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Reference: 3.7.4.1 of the 64-bit ELF V2 abi supplement.
|
|
|
|
// The general dynamic code sequence for a global `x` uses 4 instructions.
|
|
|
|
// Instruction Relocation Symbol
|
|
|
|
// addis r3, r2, x@got@tlsgd@ha R_PPC64_GOT_TLSGD16_HA x
|
|
|
|
// addi r3, r3, x@got@tlsgd@l R_PPC64_GOT_TLSGD16_LO x
|
|
|
|
// bl __tls_get_addr(x@tlsgd) R_PPC64_TLSGD x
|
|
|
|
// R_PPC64_REL24 __tls_get_addr
|
|
|
|
// nop None None
|
|
|
|
//
|
|
|
|
// Relaxing to initial-exec entails:
|
|
|
|
// 1) Convert the addis/addi pair that builds the address of the tls_index
|
|
|
|
// struct for 'x' to an addis/ld pair that loads an offset from a got-entry.
|
|
|
|
// 2) Convert the call to __tls_get_addr to a nop.
|
|
|
|
// 3) Convert the nop following the call to an add of the loaded offset to the
|
|
|
|
// thread pointer.
|
|
|
|
// Since the nop must directly follow the call, the R_PPC64_TLSGD relocation is
|
|
|
|
// used as the relaxation hint for both steps 2 and 3.
|
2020-01-23 11:42:54 +08:00
|
|
|
void PPC64::relaxTlsGdToIe(uint8_t *loc, const Relocation &rel,
|
|
|
|
uint64_t val) const {
|
|
|
|
switch (rel.type) {
|
[PPC64] Thread-local storage general-dynamic to initial-exec relaxation.
Patch adds support for relaxing the general-dynamic tls sequence to
initial-exec.
the relaxation performs the following transformation:
addis r3, r2, x@got@tlsgd@ha --> addis r3, r2, x@got@tprel@ha
addi r3, r3, x@got@tlsgd@l --> ld r3, x@got@tprel@l(r3)
bl __tls_get_addr(x@tlsgd) --> nop
nop --> add r3, r3, r13
and instead of emitting a DTPMOD64/DTPREL64 pair for x, we emit a single
R_PPC64_TPREL64.
Differential Revision: https://reviews.llvm.org/D48090
llvm-svn: 335651
2018-06-27 03:38:18 +08:00
|
|
|
case R_PPC64_GOT_TLSGD16_HA:
|
|
|
|
// This is relaxed from addis rT, r2, sym@got@tlsgd@ha to
|
|
|
|
// addis rT, r2, sym@got@tprel@ha.
|
2020-01-23 13:39:16 +08:00
|
|
|
relocateNoSym(loc, R_PPC64_GOT_TPREL16_HA, val);
|
[PPC64] Thread-local storage general-dynamic to initial-exec relaxation.
Patch adds support for relaxing the general-dynamic tls sequence to
initial-exec.
the relaxation performs the following transformation:
addis r3, r2, x@got@tlsgd@ha --> addis r3, r2, x@got@tprel@ha
addi r3, r3, x@got@tlsgd@l --> ld r3, x@got@tprel@l(r3)
bl __tls_get_addr(x@tlsgd) --> nop
nop --> add r3, r3, r13
and instead of emitting a DTPMOD64/DTPREL64 pair for x, we emit a single
R_PPC64_TPREL64.
Differential Revision: https://reviews.llvm.org/D48090
llvm-svn: 335651
2018-06-27 03:38:18 +08:00
|
|
|
return;
|
2019-07-18 18:43:07 +08:00
|
|
|
case R_PPC64_GOT_TLSGD16:
|
[PPC64] Thread-local storage general-dynamic to initial-exec relaxation.
Patch adds support for relaxing the general-dynamic tls sequence to
initial-exec.
the relaxation performs the following transformation:
addis r3, r2, x@got@tlsgd@ha --> addis r3, r2, x@got@tprel@ha
addi r3, r3, x@got@tlsgd@l --> ld r3, x@got@tprel@l(r3)
bl __tls_get_addr(x@tlsgd) --> nop
nop --> add r3, r3, r13
and instead of emitting a DTPMOD64/DTPREL64 pair for x, we emit a single
R_PPC64_TPREL64.
Differential Revision: https://reviews.llvm.org/D48090
llvm-svn: 335651
2018-06-27 03:38:18 +08:00
|
|
|
case R_PPC64_GOT_TLSGD16_LO: {
|
|
|
|
// Relax from addi r3, rA, sym@got@tlsgd@l to
|
|
|
|
// ld r3, sym@got@tprel@l(rA)
|
2019-06-12 14:00:39 +08:00
|
|
|
uint32_t ra = (readFromHalf16(loc) & (0x1f << 16));
|
|
|
|
writeFromHalf16(loc, 0xe8600000 | ra);
|
2020-01-23 13:39:16 +08:00
|
|
|
relocateNoSym(loc, R_PPC64_GOT_TPREL16_LO_DS, val);
|
[PPC64] Thread-local storage general-dynamic to initial-exec relaxation.
Patch adds support for relaxing the general-dynamic tls sequence to
initial-exec.
the relaxation performs the following transformation:
addis r3, r2, x@got@tlsgd@ha --> addis r3, r2, x@got@tprel@ha
addi r3, r3, x@got@tlsgd@l --> ld r3, x@got@tprel@l(r3)
bl __tls_get_addr(x@tlsgd) --> nop
nop --> add r3, r3, r13
and instead of emitting a DTPMOD64/DTPREL64 pair for x, we emit a single
R_PPC64_TPREL64.
Differential Revision: https://reviews.llvm.org/D48090
llvm-svn: 335651
2018-06-27 03:38:18 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
case R_PPC64_TLSGD:
|
|
|
|
write32(loc, 0x60000000); // bl __tls_get_addr(sym@tlsgd) --> nop
|
|
|
|
write32(loc + 4, 0x7c636A14); // nop --> add r3, r3, r13
|
|
|
|
return;
|
|
|
|
default:
|
|
|
|
llvm_unreachable("unsupported relocation for TLS GD to IE relaxation");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-10-17 01:13:01 +08:00
|
|
|
// The prologue for a split-stack function is expected to look roughly
|
|
|
|
// like this:
|
|
|
|
// .Lglobal_entry_point:
|
2019-10-29 09:41:38 +08:00
|
|
|
// # TOC pointer initialization.
|
2018-10-17 01:13:01 +08:00
|
|
|
// ...
|
|
|
|
// .Llocal_entry_point:
|
|
|
|
// # load the __private_ss member of the threads tcbhead.
|
|
|
|
// ld r0,-0x7000-64(r13)
|
|
|
|
// # subtract the functions stack size from the stack pointer.
|
|
|
|
// addis r12, r1, ha(-stack-frame size)
|
|
|
|
// addi r12, r12, l(-stack-frame size)
|
|
|
|
// # compare needed to actual and branch to allocate_more_stack if more
|
|
|
|
// # space is needed, otherwise fallthrough to 'normal' function body.
|
|
|
|
// cmpld cr7,r12,r0
|
2018-10-23 04:30:06 +08:00
|
|
|
// blt- cr7, .Lallocate_more_stack
|
2018-10-17 01:13:01 +08:00
|
|
|
//
|
|
|
|
// -) The allocate_more_stack block might be placed after the split-stack
|
|
|
|
// prologue and the `blt-` replaced with a `bge+ .Lnormal_func_body`
|
|
|
|
// instead.
|
|
|
|
// -) If either the addis or addi is not needed due to the stack size being
|
|
|
|
// smaller then 32K or a multiple of 64K they will be replaced with a nop,
|
|
|
|
// but there will always be 2 instructions the linker can overwrite for the
|
|
|
|
// adjusted stack size.
|
|
|
|
//
|
|
|
|
// The linkers job here is to increase the stack size used in the addis/addi
|
|
|
|
// pair by split-stack-size-adjust.
|
|
|
|
// addis r12, r1, ha(-stack-frame size - split-stack-adjust-size)
|
|
|
|
// addi r12, r12, l(-stack-frame size - split-stack-adjust-size)
|
|
|
|
bool PPC64::adjustPrologueForCrossSplitStack(uint8_t *loc, uint8_t *end,
|
|
|
|
uint8_t stOther) const {
|
|
|
|
// If the caller has a global entry point adjust the buffer past it. The start
|
|
|
|
// of the split-stack prologue will be at the local entry point.
|
|
|
|
loc += getPPC64GlobalEntryToLocalEntryOffset(stOther);
|
|
|
|
|
|
|
|
// At the very least we expect to see a load of some split-stack data from the
|
|
|
|
// tcb, and 2 instructions that calculate the ending stack address this
|
|
|
|
// function will require. If there is not enough room for at least 3
|
|
|
|
// instructions it can't be a split-stack prologue.
|
|
|
|
if (loc + 12 >= end)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// First instruction must be `ld r0, -0x7000-64(r13)`
|
|
|
|
if (read32(loc) != 0xe80d8fc0)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
int16_t hiImm = 0;
|
|
|
|
int16_t loImm = 0;
|
|
|
|
// First instruction can be either an addis if the frame size is larger then
|
|
|
|
// 32K, or an addi if the size is less then 32K.
|
|
|
|
int32_t firstInstr = read32(loc + 4);
|
|
|
|
if (getPrimaryOpCode(firstInstr) == 15) {
|
|
|
|
hiImm = firstInstr & 0xFFFF;
|
|
|
|
} else if (getPrimaryOpCode(firstInstr) == 14) {
|
|
|
|
loImm = firstInstr & 0xFFFF;
|
|
|
|
} else {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Second instruction is either an addi or a nop. If the first instruction was
|
|
|
|
// an addi then LoImm is set and the second instruction must be a nop.
|
|
|
|
uint32_t secondInstr = read32(loc + 8);
|
|
|
|
if (!loImm && getPrimaryOpCode(secondInstr) == 14) {
|
|
|
|
loImm = secondInstr & 0xFFFF;
|
|
|
|
} else if (secondInstr != 0x60000000) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// The register operands of the first instruction should be the stack-pointer
|
|
|
|
// (r1) as the input (RA) and r12 as the output (RT). If the second
|
|
|
|
// instruction is not a nop, then it should use r12 as both input and output.
|
2018-10-23 02:20:18 +08:00
|
|
|
auto checkRegOperands = [](uint32_t instr, uint8_t expectedRT,
|
|
|
|
uint8_t expectedRA) {
|
|
|
|
return ((instr & 0x3E00000) >> 21 == expectedRT) &&
|
|
|
|
((instr & 0x1F0000) >> 16 == expectedRA);
|
|
|
|
};
|
2018-10-17 01:13:01 +08:00
|
|
|
if (!checkRegOperands(firstInstr, 12, 1))
|
|
|
|
return false;
|
|
|
|
if (secondInstr != 0x60000000 && !checkRegOperands(secondInstr, 12, 12))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
int32_t stackFrameSize = (hiImm * 65536) + loImm;
|
|
|
|
// Check that the adjusted size doesn't overflow what we can represent with 2
|
|
|
|
// instructions.
|
[PPC64] Use INT32_MIN instead of std::numeric_limits<int32_t>::min()
Summary:
D53821 fixed the bogus MSVC (at least 2017) C4146 warning (unary minus applied on unsigned type)
by using std::numeric_limits<int32_t>::min().
The warning was because -2147483648 is incorrectly treated as unsigned long instead of long long)
Let's use INT32_MIN which is arguably more readable.
Note, on GCC or clang, -0x80000000 works fine (ILP64: long, LP64: long long).
Reviewers: ruiu, jhenderson, sfertile, espindola
Reviewed By: sfertile
Subscribers: emaste, nemanjai, arichardson, kbarton, jsji, llvm-commits
Differential Revision: https://reviews.llvm.org/D54200
llvm-svn: 346356
2018-11-08 05:14:54 +08:00
|
|
|
if (stackFrameSize < config->splitStackAdjustSize + INT32_MIN) {
|
2018-10-17 01:13:01 +08:00
|
|
|
error(getErrorLocation(loc) + "split-stack prologue adjustment overflows");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
int32_t adjustedStackFrameSize =
|
|
|
|
stackFrameSize - config->splitStackAdjustSize;
|
|
|
|
|
|
|
|
loImm = adjustedStackFrameSize & 0xFFFF;
|
|
|
|
hiImm = (adjustedStackFrameSize + 0x8000) >> 16;
|
|
|
|
if (hiImm) {
|
|
|
|
write32(loc + 4, 0x3D810000 | (uint16_t)hiImm);
|
|
|
|
// If the low immediate is zero the second instruction will be a nop.
|
2018-10-23 02:20:18 +08:00
|
|
|
secondInstr = loImm ? 0x398C0000 | (uint16_t)loImm : 0x60000000;
|
2018-10-17 01:13:01 +08:00
|
|
|
write32(loc + 8, secondInstr);
|
|
|
|
} else {
|
|
|
|
// addi r12, r1, imm
|
|
|
|
write32(loc + 4, (0x39810000) | (uint16_t)loImm);
|
|
|
|
write32(loc + 8, 0x60000000);
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2019-10-07 16:31:18 +08:00
|
|
|
TargetInfo *getPPC64TargetInfo() {
|
2017-06-17 04:15:03 +08:00
|
|
|
static PPC64 target;
|
|
|
|
return ⌖
|
2018-10-23 02:20:18 +08:00
|
|
|
}
|
2019-10-07 16:31:18 +08:00
|
|
|
|
|
|
|
} // namespace elf
|
|
|
|
} // namespace lld
|