Stop producing .data.rel sections.
If a section is rw, it is irrelevant if the dynamic linker will write to
it or not.
It looks like llvm implemented this because gcc was doing it. It looks
like gcc implemented this in the hope that it would put all the
relocated items close together and speed up the dynamic linker.
There are two problem with this:
* It doesn't work. Both bfd and gold will map .data.rel to .data and
concatenate the input sections in the order they are seen.
* If we want a feature like that, it can be implemented directly in the
linker since it knowns where the dynamic relocations are.
llvm-svn: 253436
diff --git a/llvm/test/CodeGen/AArch64/emutls_generic.ll b/llvm/test/CodeGen/AArch64/emutls_generic.ll
index b06c647..7664db3 100644
--- a/llvm/test/CodeGen/AArch64/emutls_generic.ll
+++ b/llvm/test/CodeGen/AArch64/emutls_generic.ll
@@ -47,7 +47,7 @@
; ARM_64: .section .rodata,
; ARM_64-LABEL: __emutls_t.external_y:
; ARM_64-NEXT: .byte 7
-; ARM_64: .section .data.rel
+; ARM_64: .data
; ARM_64: .align 3
; ARM_64-LABEL: __emutls_v.internal_y:
; ARM_64-NEXT: .xword 8
diff --git a/llvm/test/CodeGen/AArch64/pic-eh-stubs.ll b/llvm/test/CodeGen/AArch64/pic-eh-stubs.ll
index 143558f..c59a5b6 100644
--- a/llvm/test/CodeGen/AArch64/pic-eh-stubs.ll
+++ b/llvm/test/CodeGen/AArch64/pic-eh-stubs.ll
@@ -15,7 +15,7 @@
; CHECK-NEXT: .xword .L_ZTIi.DW.stub-[[TYPEINFO_LBL]]
; .. and which is properly defined (in a writable section for the dynamic loader) later.
-; CHECK: .section .data.rel,"aw"
+; CHECK: .data
; CHECK: .L_ZTIi.DW.stub:
; CHECK-NEXT: .xword _ZTIi