public inbox for binutils-cvs@sourceware.org
help / color / mirror / Atom feed
From: Alan Modra <amodra@sourceware.org>
To: bfd-cvs@sourceware.org
Subject: [binutils-gdb/binutils-2_39-branch] Re: PowerPC64 .branch_lt address
Date: Mon, 25 Jul 2022 02:24:34 +0000 (GMT)	[thread overview]
Message-ID: <20220725022434.2BBDF385828B@sourceware.org> (raw)

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;


                 reply	other threads:[~2022-07-25  2:24 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20220725022434.2BBDF385828B@sourceware.org \
    --to=amodra@sourceware.org \
    --cc=bfd-cvs@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).