public inbox for gdb-testers@sourceware.org
help / color / mirror / Atom feed
From: sergiodj+buildbot@sergiodj.net
To: gdb-testers@sourceware.org
Subject: [binutils-gdb] PowerPC PLT16 relocations
Date: Mon, 09 Apr 2018 08:49:00 -0000	[thread overview]
Message-ID: <08be322439408ac02cff2ac9b5eca4f7243a0277@gdb-build> (raw)

*** TEST RESULTS FOR COMMIT 08be322439408ac02cff2ac9b5eca4f7243a0277 ***

Author: Alan Modra <amodra@gmail.com>
Branch: master
Commit: 08be322439408ac02cff2ac9b5eca4f7243a0277

PowerPC PLT16 relocations

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.


             reply	other threads:[~2018-04-09  8:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-09  8:49 sergiodj+buildbot [this message]
2018-04-09  8:49 ` Failures on RHEL-s390x-m64, branch master sergiodj+buildbot
2018-04-09  9:25 ` Failures on Fedora-x86_64-native-gdbserver-m32, " sergiodj+buildbot
2018-04-09  9:28 ` Failures on Fedora-x86_64-m32, " sergiodj+buildbot
2018-04-09  9:56 ` Failures on Fedora-x86_64-m64, " sergiodj+buildbot
2018-04-09  9:59 ` Failures on Fedora-i686, " sergiodj+buildbot
2018-04-09 10:00 ` Failures on Fedora-x86_64-native-gdbserver-m64, " sergiodj+buildbot
2018-04-09 10:02 ` Failures on Fedora-x86_64-native-extended-gdbserver-m64, " sergiodj+buildbot
2018-04-09 10:36 ` Failures on Debian-s390x-native-gdbserver-m64, " sergiodj+buildbot
2018-04-09 12:04 ` Failures on Ubuntu-AArch32-native-extended-gdbserver-m32, " sergiodj+buildbot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=08be322439408ac02cff2ac9b5eca4f7243a0277@gdb-build \
    --to=sergiodj+buildbot@sergiodj.net \
    --cc=gdb-testers@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).