public inbox for gdb-testers@sourceware.org
help / color / mirror / Atom feed
From: gdb-buildbot@sergiodj.net
To: gdb-testers@sourceware.org
Subject: [binutils-gdb] [PR ld/22263][PR ld/25056] arm: Avoid dynamic TLS relocs in PIE
Date: Fri, 11 Oct 2019 10:59:00 -0000	[thread overview]
Message-ID: <9cb09e33e04feb12df2aaa6e81d61b82ad609ce5@gdb-build> (raw)

*** TEST RESULTS FOR COMMIT 9cb09e33e04feb12df2aaa6e81d61b82ad609ce5 ***

commit 9cb09e33e04feb12df2aaa6e81d61b82ad609ce5
Author:     Szabolcs Nagy <szabolcs.nagy@arm.com>
AuthorDate: Wed Oct 2 19:46:46 2019 +0100
Commit:     Szabolcs Nagy <szabolcs.nagy@arm.com>
CommitDate: Fri Oct 4 10:57:00 2019 +0100

    [PR ld/22263][PR ld/25056] arm: Avoid dynamic TLS relocs in PIE
    
    Dynamic relocs are only needed in an executable for TLS symbols if
    those are defined in an external module and even then TLS access
    can be relaxed to use IE model instead of GD.
    
    Several bfd_link_pic checks are turned into bfd_link_dll checks
    to fix TLS handling in PIE, for the same fix some other targets
    used !bfd_link_executable checks, but that includes relocatable
    objects so dll seems safer (in most cases either should work, since
    dynamic relocations are not applied in relocatable objects).
    
    On arm* fixes
    FAIL: Build pr22263-1
    
    bfd/
    
            PR ld/22263
            PR ld/25056
            * elf32-arm.c (elf32_arm_tls_transition): Use bfd_link_dll instead of
            bfd_link_pic for TLS checks.
            (elf32_arm_final_link_relocate): Likewise.
            (allocate_dynrelocs_for_symbol): Likewise.

diff --git a/bfd/ChangeLog b/bfd/ChangeLog
index 85dc6b26be..a2e3bb090f 100644
--- a/bfd/ChangeLog
+++ b/bfd/ChangeLog
@@ -1,3 +1,12 @@
+2019-10-04  Szabolcs Nagy  <szabolcs.nagy@arm.com>
+
+	PR ld/22263
+	PR ld/25056
+	* elf32-arm.c (elf32_arm_tls_transition): Use bfd_link_dll instead of
+	bfd_link_pic for TLS checks.
+	(elf32_arm_final_link_relocate): Likewise.
+	(allocate_dynrelocs_for_symbol): Likewise.
+
 2019-10-04  Szabolcs Nagy  <szabolcs.nagy@arm.com>
 
 	PR ld/25062
diff --git a/bfd/elf32-arm.c b/bfd/elf32-arm.c
index d52c046979..9837350d06 100644
--- a/bfd/elf32-arm.c
+++ b/bfd/elf32-arm.c
@@ -4914,7 +4914,7 @@ elf32_arm_tls_transition (struct bfd_link_info *info, int r_type,
 {
   int is_local = (h == NULL);
 
-  if (bfd_link_pic (info)
+  if (bfd_link_dll (info)
       || (h && h->root.type == bfd_link_hash_undefweak))
     return r_type;
 
@@ -11700,7 +11700,7 @@ elf32_arm_final_link_relocate (reloc_howto_type *	    howto,
 	  {
 	    /* If we don't know the module number, create a relocation
 	       for it.  */
-	    if (bfd_link_pic (info))
+	    if (bfd_link_dll (info))
 	      {
 		Elf_Internal_Rela outrel;
 
@@ -11804,7 +11804,7 @@ elf32_arm_final_link_relocate (reloc_howto_type *	    howto,
 	       now, and emit any relocations.  If both an IE GOT and a
 	       GD GOT are necessary, we emit the GD first.  */
 
-	    if ((bfd_link_pic (info) || indx != 0)
+	    if ((bfd_link_dll (info) || indx != 0)
 		&& (h == NULL
 		    || (ELF_ST_VISIBILITY (h->other) == STV_DEFAULT
 			&& !resolved_to_zero)
@@ -11821,7 +11821,7 @@ elf32_arm_final_link_relocate (reloc_howto_type *	    howto,
 		/* We should have relaxed, unless this is an undefined
 		   weak symbol.  */
 		BFD_ASSERT ((h && (h->root.type == bfd_link_hash_undefweak))
-			    || bfd_link_pic (info));
+			    || bfd_link_dll (info));
 		BFD_ASSERT (globals->sgotplt_jump_table_size + offplt + 8
 			    <= globals->root.sgotplt->size);
 
@@ -16494,7 +16494,7 @@ allocate_dynrelocs_for_symbol (struct elf_link_hash_entry *h, void * inf)
 	    indx = h->dynindx;
 
 	  if (tls_type != GOT_NORMAL
-	      && (bfd_link_pic (info) || indx != 0)
+	      && (bfd_link_dll (info) || indx != 0)
 	      && (ELF_ST_VISIBILITY (h->other) == STV_DEFAULT
 		  || h->root.type != bfd_link_hash_undefweak))
 	    {


             reply	other threads:[~2019-10-11 10:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-11 10:59 gdb-buildbot [this message]
2019-10-11 10:59 ` Failures on Ubuntu-Aarch64-m64, branch master gdb-buildbot
2019-10-11 13:50 ` Failures on Ubuntu-Aarch64-native-extended-gdbserver-m64, " gdb-buildbot
2019-10-11 15:30 ` Failures on Ubuntu-Aarch64-native-gdbserver-m64, " gdb-buildbot
2019-10-14 14:38 ` Failures on Fedora-i686, " gdb-buildbot
2019-10-14 16:16 ` Failures on Fedora-x86_64-cc-with-index, " gdb-buildbot
2019-10-14 17:40 ` Failures on Fedora-x86_64-m32, " gdb-buildbot
2019-10-14 17:51 ` Failures on Fedora-x86_64-m64, " gdb-buildbot
2019-10-14 19:28 ` Failures on Fedora-x86_64-native-extended-gdbserver-m32, " gdb-buildbot
2019-10-14 21:00 ` Failures on Fedora-x86_64-native-gdbserver-m32, " gdb-buildbot
2019-10-14 21:24 ` Failures on Fedora-x86_64-native-gdbserver-m64, " gdb-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=9cb09e33e04feb12df2aaa6e81d61b82ad609ce5@gdb-build \
    --to=gdb-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).