public inbox for binutils-cvs@sourceware.org
help / color / mirror / Atom feed
* [binutils-gdb/binutils-2_39-branch] Re: PowerPC64 .branch_lt address
@ 2022-07-25 2:24 Alan Modra
0 siblings, 0 replies; only message in thread
From: Alan Modra @ 2022-07-25 2:24 UTC (permalink / raw)
To: bfd-cvs
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=97acb51d6ac5b3e09b5817edc7a41678d96e945c
commit 97acb51d6ac5b3e09b5817edc7a41678d96e945c
Author: Alan Modra <amodra@gmail.com>
Date: Mon Jul 25 09:25:49 2022 +0930
Re: PowerPC64 .branch_lt address
On seeing PR29369 my suspicion was naturally on a recent powerpc64
change, commit 0ab80031430e. Without a reproducer, I spent time
wondering what could have gone wrong, and while I doubt this patch
would have fixed the PR, there are some improvements that can be made
to cater for user silliness.
I also noticed that when -z relro -z now sections are created out of
order, with .got before .plt in the section headers but .got is laid
out at a higher address. That's due to the address expression for
.branch_lt referencing SIZEOF(.got) and so calling init_os (which
creates a bfd section) for .got before the .plt section is created.
Fix that by ignoring SIZEOF in exp_init_os. Unlike ADDR and LOADADDR
which need to reference section vma and lma respectively, SIZEOF can
and does cope with a missing bfd section by returning zero for its
size, which of course is correct.
PR 29369
* ldlang.c (exp_init_os): Don't create a bfd section for SIZEOF.
* emulparams/elf64ppc.sh (OTHER_RELRO_SECTIONS_2): Revise
.branch_lt address to take into account possible user sections
with alignment larger than 8 bytes.
(cherry picked from commit 5d471bd907be60e9858b22cdf4fd10ddc0f6ee1a)
Diff:
---
ld/emulparams/elf64ppc.sh | 22 +++++++++++++++++++++-
ld/ldlang.c | 1 -
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/ld/emulparams/elf64ppc.sh b/ld/emulparams/elf64ppc.sh
index 59132fa06fa..668606e7c18 100644
--- a/ld/emulparams/elf64ppc.sh
+++ b/ld/emulparams/elf64ppc.sh
@@ -34,10 +34,30 @@ OTHER_GOT_RELOC_SECTIONS="
.rela.toc1 ${RELOCATING-0} : { *(.rela.toc1) }
.rela.tocbss ${RELOCATING-0} : { *(.rela.tocbss) }
.rela.branch_lt ${RELOCATING-0} : { *(.rela.branch_lt) }"
+# The idea behind setting .branch_lt address as we do below is to put
+# it up against .got which is 256 byte aligned, so that the offset
+# from .TOC. to an entry in .branch_lt remains fixed after stub
+# sizing. (.eh_frame is edited late.) When -z relro -z now, we have
+# .branch_lt, .plt, .iplt, then .got, so in that case we move
+# .branch_lt so that the end of .iplt is against .got. All of these
+# sections are linker generated, with alignment eight and size a
+# multiple of eight, but a user playing games with their own
+# .branch_lt, .plt or .iplt sections can result in unexpected
+# alignment or size. Cope with that anyway. Note that if user
+# alignment of .branch_lt is 256 or more then nothing special need be
+# done.
+#
+# To understand what is going on here consider that the end address
+# of .iplt should be 0 mod 256, so the start of .iplt should be
+# -sizeof(.iplt) mod 256. But the start is constrained by alignment,
+# so goes down to (-alignof(.iplt) & -sizeof(.iplt)) mod 256. Repeat
+# that calculation for .plt and .branch_lt to find the start of
+# .branch_lt then subtract . mod 256 to find the padding. Of course
+# just one mod 256 suffices, which is done by anding with 255.
OTHER_RELRO_SECTIONS_2="
.opd ${RELOCATING-0} :${RELOCATING+ ALIGN(8)} { KEEP (*(.opd)) }
.toc1 ${RELOCATING-0} :${RELOCATING+ ALIGN(8)} { *(.toc1) }
- .branch_lt ${RELOCATING-0}${RELOCATING+(SIZEOF(.got) != 0 ? . + 255 - (255 & (. - 1 + ALIGN(SIZEOF(.branch_lt),8)${RELRO_NOW+ + ALIGN(SIZEOF(.plt),8) + ALIGN(SIZEOF(.iplt),8)})) : ALIGN(8))} : { *(.branch_lt) }"
+ .branch_lt ${RELOCATING-0}${RELOCATING+ALIGNOF(.branch_lt) < 256 && SIZEOF(.got) != 0 ? . + (((-MAX(ALIGNOF(.branch_lt),8) & (-SIZEOF(.branch_lt)${RELRO_NOW+ + (-MAX(ALIGNOF(.plt),8) & (-SIZEOF(.plt) + (-MAX(ALIGNOF(.iplt),8) & -SIZEOF(.iplt))))})) - .) & 255) : ALIGN(MAX(ALIGNOF(.branch_lt), SIZEOF(.got) != 0 ? 256 : 8))} : { *(.branch_lt) }"
INITIAL_READWRITE_SECTIONS="
.toc ${RELOCATING-0} :${RELOCATING+ ALIGN(8)} { *(.toc) }"
# Put .got before .data
diff --git a/ld/ldlang.c b/ld/ldlang.c
index e640380e901..f12c09633a7 100644
--- a/ld/ldlang.c
+++ b/ld/ldlang.c
@@ -2458,7 +2458,6 @@ exp_init_os (etree_type *exp)
{
case ADDR:
case LOADADDR:
- case SIZEOF:
{
lang_output_section_statement_type *os;
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2022-07-25 2:24 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-25 2:24 [binutils-gdb/binutils-2_39-branch] Re: PowerPC64 .branch_lt address Alan Modra
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).