The PowerPC64 ELFv2 ABI and the PowerPC SysV ABI support a number of
relocations that can be used to create and access a PLT entry.
However, the relocs are not well defined. The PLT16 family of relocs
talk about "the section offset or address of the procedure linkage
table entry". It's plain that we do need a relative address when PIC
as otherwise we'd have dynamic text relocations, but "section offset"
doesn't specify which section. The most obvious one, ".plt", isn't
that useful because there is no readily available way of addressing
the start of the ".plt" section. Much more useful would be "the
GOT/TOC-pointer relative offset of the procedure linkage table entry",
and I suppose you could argue that is a "section offset" of sorts.
For PowerPC64 it is better to use the same TOC-pointer relative
addressing even when non-PIC, since ".plt" may be located outside the
range of a 32-bit address. However, for ppc32 we do want an absolute
address when non-PIC as a GOT pointer may not be set up. Also, for
ppc32 PIC we have a similar situation to R_PPC_PLTREL24 in that the
GOT pointer is set to a location in the .got2 section and we need to
specify the .got2 offset in the PLT16 reloc addend.
This patch supports PLT16 relocations using these semantics. This is
not an ABI change for ppc32 since the relocations were not previously
supported by GNU ld, but is for ppc64 where some of the PLT16 relocs
were supported. I'm not particularly concerned since the old ppc64
PLT16 reloc semantics made them almost completely useless.
bfd/
* elf32-ppc.c (ppc_elf_check_relocs): Handle PLT16 relocs.
(ppc_elf_relocate_section): Likewise.
* elf64-ppc.c (ppc64_elf_check_relocs): Handle PLT16_LO_DS.
(ppc64_elf_relocate_section): Likewise. Correct PLT16
resolution to plt entry relative to toc pointer.
gold/
* powerpc.cc (Target_powerpc::plt_off): New functions.
(is_plt16_reloc): New function.
(Stub_table::plt_off): Use Target_powerpc::plt_off.
(Stub_table::plt_call_size): Use plt_off.
(Stub_table::do_write): Likewise.
(Target_powerpc::Scan::get_reference_flags): Return RELATIVE_REF
for PLT16 relocations.
(Target_powerpc::Scan::reloc_needs_plt_for_ifunc): Return true
for PLT16 relocations.
(Target_powerpc::Scan::global): Make a PLT entry for PLT16 relocations.
(Target_powerpc::Relocate::relocate): Support PLT16 relocations.
(Powerpc_scan_relocatable_reloc::global_strategy): Return RELOC_SPECIAL
for ppc32 plt16 relocs.
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
gold is an ELF linker. It is intended to have complete support for
ELF and to run as fast as possible on modern systems. For normal use
it is a drop-in replacement for the older GNU linker.
gold is part of the GNU binutils. See ../binutils/README for more
general notes, including where to send bug reports.
gold was originally developed at Google, and was contributed to the
Free Software Foundation in March 2008. At Google it was designed by
Ian Lance Taylor, with major contributions by Cary Coutant, Craig
Silverstein, and Andrew Chatham.
The existing GNU linker manual is intended to be accurate
documentation for features which gold supports. gold supports most of
the features of the GNU linker for ELF targets. Notable
omissions--features of the GNU linker not currently supported in
gold--are:
* MRI compatible linker scripts
* cross-reference reports (--cref)
* various other minor options
Notes on the code
=================
These are some notes which may be helpful to people working on the
source code of gold itself.
gold is written in C++. It is a GNU program, and therefore follows
the GNU formatting standards as modified for C++. Source documents in
order of decreasing precedence:
http://www.gnu.org/prep/standards/
http://gcc.gnu.org/onlinedocs/libstdc++/manual/source_code_style.html
http://www.zembu.com/eng/procs/c++style.html
The linker is intended to have complete support for cross-compilation,
while still supporting the normal case of native linking as fast as
possible. In order to do this, many classes are actually templates
whose parameter is the ELF file class (e.g., 32 bits or 64 bits). The
C++ code is the same, but we don't pay the execution time cost of
always using 64-bit integers if the target is 32 bits. Many of these
class templates also have an endianness parameter: true for
big-endian, false for little-endian.
The linker is multi-threaded. The Task class represents a single unit
of work. Task objects are stored on a single Workqueue object. Tasks
communicate via Task_token objects. Task_token objects are only
manipulated while holding the master Workqueue lock. Relatively few
mutexes are used.
Build requirements
==================
The gold source code uses templates heavily. Building it requires a
recent version of g++. g++ 4.0.3 and 4.1.3 are known to work. g++
3.2, 3.4.3, and 4.1.2 are known to fail.
The linker script parser uses features which are only in newer
versions of bison. bison 2.3 is known to work. bison 1.26 is known
to fail. If you are building gold from an official binutils release,
the bison output should already be included.
Copyright (C) 2012-2018 Free Software Foundation, Inc.
Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved.
08be322439