[all-commits] [llvm/llvm-project] 6f8ad1: [ELF][PPC32] Support canonical PLT

[Fangrui Song via All-commits]

  Branch: refs/heads/release/10.x
  Home:   https://github.com/llvm/llvm-project
  Commit: 6f8ad14521ec2983f2398bae32a717842e2cf313
      https://github.com/llvm/llvm-project/commit/6f8ad14521ec2983f2398bae32a717842e2cf313
  Author: Fangrui Song <i at maskray.me>
  Date:   2020-01-25 (Sat, 25 Jan 2020)

  Changed paths:
    M lld/ELF/Arch/PPC.cpp
    M lld/ELF/Relocations.cpp
    M lld/ELF/SyntheticSections.cpp
    M lld/ELF/SyntheticSections.h
    A lld/test/ELF/ppc32-canonical-plt.s

  Log Message:
  -----------
  [ELF][PPC32] Support canonical PLT

-fno-pie produces a pair of non-GOT-non-PLT relocations R_PPC_ADDR16_{HA,LO} (R_ABS) referencing external
functions.

```
lis 3, func at ha
la 3, func at l(3)
```

In a -no-pie/-pie link, if func is not defined in the executable, a canonical PLT entry (st_value>0, st_shndx=0) will be needed.
References to func in shared objects will be resolved to this address.
-fno-pie -pie should fail with "can't create dynamic relocation ... against ...", so we just need to think about -no-pie.

On x86, the PLT entry passes the JMP_SLOT offset to the rtld PLT resolver.
On x86-64: the PLT entry passes the JUMP_SLOT index to the rtld PLT resolver.
On ARM/AArch64: the PLT entry passes &.got.plt[n]. The PLT header passes &.got.plt[fixed-index]. The rtld PLT resolver can compute the JUMP_SLOT index from the two addresses.

For these targets, the canonical PLT entry can just reuse the regular PLT entry (in PltSection).

On PPC32: PltSection (.glink) consists of `b PLTresolve` instructions and `PLTresolve`. The rtld PLT resolver depends on r11 having been set up to the .plt (GotPltSection) entry.
On PPC64 ELFv2: PltSection (.glink) consists of `__glink_PLTresolve` and `bl __glink_PLTresolve`. The rtld PLT resolver depends on r12 having been set up to the .plt (GotPltSection) entry.

We cannot reuse a `b PLTresolve`/`bl __glink_PLTresolve` in PltSection as a canonical PLT entry. PPC64 ELFv2 avoids the problem by using TOC for any external reference, even in non-pic code, so the canonical PLT entry scenario should not happen in the first place.
For PPC32, we have to create a PLT call stub as the canonical PLT entry. The code sequence sets up r11.

Reviewed By: Bdragon28

Differential Revision: https://reviews.llvm.org/D73399

(cherry picked from commit 837e8a9c0cd097034e023dfba146d17ce132998c)