This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Sort relocs output by ld -r
- From: Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: binutils at sourceware dot org
- Date: Fri, 13 Mar 2015 20:51:25 +0100
- Subject: Re: Sort relocs output by ld -r
- Authentication-results: sourceware.org; auth=none
- References: <20141204072210 dot GW20383 at bubble dot grove dot modra dot org>
On Thu, Dec 04, 2014 at 05:52:10PM +1030, Alan Modra wrote:
> Applying to master.
>
> bfd/
> PR 17666
> * elflink.c: Include bfd_stdint.h.
> (cmp_ext32l_r_offset, cmp_ext32b_r_offset,
> cmp_ext64l_r_offset, cmp_ext64b_r_offset): New functions.
> (elf_link_adjust_relocs): Sort relocs. Free reloc hashes after
> sorting invalidates.
> ld/testsuite/
> * ld-powerpc/vxworks-relax.rd: Update for reloc sorting.
> * ld-powerpc/vxworks-relax-2.rd: Likewise.
> * ld-sh/sh64/reldl32.rd: Likewise.
> * ld-sh/sh64/reldl64.rd: Likewise.
This seems to be break the linker TLS optimizations on S/390 :(
When downgrading from GD to IE model we rewrite the call to
__tls_get_offset to a 64 bit load instruction. This relies on the fact
that the additional relocation for the call target has already been
executed when doing the rewrite.
f1018: e3 20 d0 00 00 04 lg %r2,0(%r13)
f101e: c0 e5 00 00 00 00 brasl %r14,f101e <__res_init+0x1e>
f101e: R_390_TLS_GDCALL __libc_resp
f1020: R_390_PLT32DBL __tls_get_offset+0x2
0000000f1020 39f6c00000014 R_390_PLT32DBL 0000000000000000 __tls_get_offset + 2
0000000f101e 3afb700000026 R_390_TLS_GDCALL 0000000000000008 __libc_resp + 0
Due to the reloc sorting the order changed an the PLT32DBL reloc is
executed after the rewrite and overwrites part of the load instruction
with garbage.
0000000f101e 3afb700000026 R_390_TLS_GDCALL 0000000000000008 __libc_resp + 0
0000000f1020 39f6c00000014 R_390_PLT32DBL 0000000000000000 __tls_get_offset + 2
The attached patch mimics what you did for Mips and disables the
sorting for relocations against code section. Does that look like a
reasonable fix for this case as well?
Alternatively we might also try to get rid of this dependency.
Bye,
-Andreas-
bfd/
2015-03-13 Andreas Krebbel <krebbel@linux.vnet.ibm.com>
* elf-s390-common.c (elf_s390_elf_sort_relocs_p): Don't sort
relocs against code sections.
* elf32-s390.c: Define elf_backend_sort_relocs_p.
* elf64-s390.c: Likewise.
diff --git a/bfd/elf-s390-common.c b/bfd/elf-s390-common.c
index 6fd1027..462da16 100644
--- a/bfd/elf-s390-common.c
+++ b/bfd/elf-s390-common.c
@@ -242,3 +242,15 @@ elf_s390_add_symbol_hook (bfd *abfd,
return TRUE;
}
+
+/* Whether to sort relocs output by ld -r or ld --emit-relocs, by
+ r_offset. Don't do so for code sections. We want to keep ordering
+ of GDCALL / PLT32DBL for TLS optimizations as is. On the other
+ hand, elf-eh-frame.c processing requires .eh_frame relocs to be
+ sorted. */
+
+static bfd_boolean
+elf_s390_elf_sort_relocs_p (asection *sec)
+{
+ return (sec->flags & SEC_CODE) == 0;
+}
diff --git a/bfd/elf32-s390.c b/bfd/elf32-s390.c
index f5403e2..0127eab 100644
--- a/bfd/elf32-s390.c
+++ b/bfd/elf32-s390.c
@@ -4028,6 +4028,7 @@ elf32_s390_merge_private_bfd_data (bfd *ibfd, bfd *obfd)
#define elf_backend_grok_prstatus elf_s390_grok_prstatus
#define elf_backend_plt_sym_val elf_s390_plt_sym_val
#define elf_backend_add_symbol_hook elf_s390_add_symbol_hook
+#define elf_backend_sort_relocs_p elf_s390_elf_sort_relocs_p
#define bfd_elf32_mkobject elf_s390_mkobject
#define elf_backend_object_p elf_s390_object_p
diff --git a/bfd/elf64-s390.c b/bfd/elf64-s390.c
index e002f06..f06b58a 100644
--- a/bfd/elf64-s390.c
+++ b/bfd/elf64-s390.c
@@ -3840,6 +3840,7 @@ const struct elf_size_info s390_elf64_size_info =
#define elf_backend_init_index_section _bfd_elf_init_1_index_section
#define elf_backend_plt_sym_val elf_s390_plt_sym_val
#define elf_backend_add_symbol_hook elf_s390_add_symbol_hook
+#define elf_backend_sort_relocs_p elf_s390_elf_sort_relocs_p
#define bfd_elf64_mkobject elf_s390_mkobject
#define elf_backend_object_p elf_s390_object_p