[AArch64 ] Generate long branch veneer if call to plt stub is out of range

[AArch64 ] Generate long branch veneer if call to plt stub is out of range

[Jiong Wang]

If text section size is really big, when the linker redirect function
call to plt stub, the branch offset may be out of range.

Currently, AArch64 BFD has long branch veneer infrastructure ready, but
it's not enabled for call to plt stub. Only absolute call long branch
implemented while for PIC/.so, call to PLT stub is the common case and
we need to support this.

This patch copied some code from ARM32, and cleaned up code logic in
final_link code where BFD_RELOC_AARCH64_JUMP26/CALL26 handled.

The code logic for handling CALL26/JUMP26 is simplied into:

  * if it call via plt stub, then update relocation value to plt stub address.
  * use the updated relocation value to check whether it's fit into range.
    And if the offset don't fit into the range then check whether any
    long branch veneer register for it.
  * if long branch veneer register, then udpate final relocation value
    to the address of veneer, otherwise don't touch relocation value.

test done
===
  native ld check OK.
  linking the huge OpenLoop reported on PR 18668 successfully which
  failed on the old bfd linker.
  

OK for trunk?

2015-07-15  Jiong Wang  <jiong.wang@arm.com>
bfd/
  PR ld/18668
  * elfnn-aarch64.c (aarch64_type_of_stub): Update destination for
  calls go through plt stub.
  (elfNN_aarch64_final_link_relocate): Adjust code logic for CALL26,
  JUMP26 relocation to support inserting veneer for call to plt stub.

ld/testsuite/
  * ld-aarch64/farcall-b-gsym.s: New test.
  * ld-aarch64/farcall-b-plt.s: Ditto.
  * ld-aarch64/farcall-bl-plt.s: Ditto.
  * ld-aarch64/farcall-b-gsym.d: New expect file.
  * ld-aarch64/farcall-b-plt.d: Ditto.
  * ld-aarch64/farcall-bl-plt.d: Ditto.

OK for trunk?
-- 
Regards,
Jiong

[AArch64] PR18668, Generate long branch veneer if call to plt stub is out of range

[Jiong Wang]

[-- Attachment #1: Type: text/plain, Size: 1793 bytes --]


(add the patch)

If text section size is really big, when the linker redirect function
call to plt stub, the branch offset may be out of range.

Currently, AArch64 BFD has long branch veneer infrastructure ready, but
it's not enabled for call to plt stub. Only absolute call long branch
implemented while for PIC/.so, call to PLT stub is the common case and
we need to support this.

This patch copied some code from ARM32, and cleaned up code logic in
final_link code where BFD_RELOC_AARCH64_JUMP26/CALL26 handled.

The code logic for handling CALL26/JUMP26 is simplied into:

  * if it call via plt stub, then update relocation value to plt stub address.
  * use the updated relocation value to check whether it's fit into range.
    And if the offset don't fit into the range then check whether any
    long branch veneer register for it.
  * if long branch veneer register, then udpate final relocation value
    to the address of veneer, otherwise don't touch relocation value.

test done
===
  native ld check OK.
  linking the huge OpenLoop reported on PR 18668 successfully which
  failed on the old bfd linker.
  

OK for trunk?

2015-07-15  Jiong Wang  <jiong.wang@arm.com>
bfd/
  PR ld/18668
  * elfnn-aarch64.c (aarch64_type_of_stub): Update destination for
  calls go through plt stub.
  (elfNN_aarch64_final_link_relocate): Adjust code logic for CALL26,
  JUMP26 relocation to support inserting veneer for call to plt stub.

ld/testsuite/
  * ld-aarch64/farcall-b-gsym.s: New test.
  * ld-aarch64/farcall-b-plt.s: Ditto.
  * ld-aarch64/farcall-bl-plt.s: Ditto.
  * ld-aarch64/farcall-b-gsym.d: New expect file.
  * ld-aarch64/farcall-b-plt.d: Ditto.
  * ld-aarch64/farcall-bl-plt.d: Ditto.

OK for trunk?
-- 
Regards,
Jiong


[-- Attachment #2: plt-veneer.patch --]
[-- Type: text/x-diff, Size: 7807 bytes --]

commit 8d3fa62f5ab58a7e30968422dd3238470f7f067d
Author: Jiong Wang <jiong.wang@arm.com>
Date:   Wed Jul 15 14:26:40 2015 +0000

    1

diff --git a/bfd/elfnn-aarch64.c b/bfd/elfnn-aarch64.c
index c252b13..e05a5da 100644
--- a/bfd/elfnn-aarch64.c
+++ b/bfd/elfnn-aarch64.c
@@ -2222,9 +2222,11 @@ aarch64_type_of_stub (struct bfd_link_info *info,
   globals = elf_aarch64_hash_table (info);
   via_plt_p = (globals->root.splt != NULL && hash != NULL
 	       && hash->root.plt.offset != (bfd_vma) - 1);
-
+  /* Make sure call to plt stub can fit into the branch range.  */
   if (via_plt_p)
-    return stub_type;
+    destination = (globals->root.splt->output_section->vma
+		   + globals->root.splt->output_offset
+		   + hash->root.plt.offset);
 
   /* Determine where the call point is.  */
   location = (input_sec->output_offset
@@ -4766,38 +4768,25 @@ elfNN_aarch64_final_link_relocate (reloc_howto_type *howto,
 	/* If the call goes through a PLT entry, make sure to
 	   check distance to the right destination address.  */
 	if (via_plt_p)
-	  {
-	    value = (splt->output_section->vma
-		     + splt->output_offset + h->plt.offset);
-	    *unresolved_reloc_p = FALSE;
-	  }
-
-	/* If the target symbol is global and marked as a function the
-	   relocation applies a function call or a tail call.  In this
-	   situation we can veneer out of range branches.  The veneers
-	   use IP0 and IP1 hence cannot be used arbitrary out of range
-	   branches that occur within the body of a function.  */
-	if (h && h->type == STT_FUNC)
-	  {
-	    /* Check if a stub has to be inserted because the destination
-	       is too far away.  */
-	    if (! aarch64_valid_branch_p (value, place))
-	      {
-		/* The target is out of reach, so redirect the branch to
-		   the local stub for this function.  */
-		struct elf_aarch64_stub_hash_entry *stub_entry;
-		stub_entry = elfNN_aarch64_get_stub_entry (input_section,
-							   sym_sec, h,
-							   rel, globals);
-		if (stub_entry != NULL)
-		  value = (stub_entry->stub_offset
-			   + stub_entry->stub_sec->output_offset
-			   + stub_entry->stub_sec->output_section->vma);
-	      }
-	  }
+	  value = (splt->output_section->vma
+		   + splt->output_offset + h->plt.offset);
+
+	/* Check if a stub has to be inserted because the destination
+	   is too far away.  */
+	struct elf_aarch64_stub_hash_entry *stub_entry = NULL;
+	if (! aarch64_valid_branch_p (value, place))
+	  /* The target is out of reach, so redirect the branch to
+	     the local stub for this function.  */
+	stub_entry = elfNN_aarch64_get_stub_entry (input_section, sym_sec, h,
+						   rel, globals);
+	if (stub_entry != NULL)
+	  value = (stub_entry->stub_offset
+		   + stub_entry->stub_sec->output_offset
+		   + stub_entry->stub_sec->output_section->vma);
       }
       value = _bfd_aarch64_elf_resolve_relocation (bfd_r_type, place, value,
 						   signed_addend, weak_undef_p);
+      *unresolved_reloc_p = FALSE;
       break;
 
     case BFD_RELOC_AARCH64_ADR_LO21_PCREL:
diff --git a/ld/testsuite/ld-aarch64/aarch64-elf.exp b/ld/testsuite/ld-aarch64/aarch64-elf.exp
index bfbbe24..99f2f6f 100644
--- a/ld/testsuite/ld-aarch64/aarch64-elf.exp
+++ b/ld/testsuite/ld-aarch64/aarch64-elf.exp
@@ -113,6 +113,9 @@ run_dump_test "limit-b"
 run_dump_test "limit-bl"
 run_dump_test "farcall-section"
 run_dump_test "farcall-back"
+run_dump_test "farcall-b-gsym"
+run_dump_test "farcall-b-plt"
+run_dump_test "farcall-bl-plt"
 run_dump_test "farcall-bl"
 run_dump_test "farcall-b"
 run_dump_test "farcall-b-none-function"
diff --git a/ld/testsuite/ld-aarch64/farcall-b-gsym.d b/ld/testsuite/ld-aarch64/farcall-b-gsym.d
new file mode 100644
index 0000000..eced18e
--- /dev/null
+++ b/ld/testsuite/ld-aarch64/farcall-b-gsym.d
@@ -0,0 +1,5 @@
+#name: aarch64-farcall-b-gsym
+#source: farcall-b-gsym.s
+#as:
+#ld: -Ttext 0x1000
+#error: .*\(.text\+0x0\): relocation truncated to fit: R_AARCH64_JUMP26 against symbol `bar_gsym'.*
diff --git a/ld/testsuite/ld-aarch64/farcall-b-gsym.s b/ld/testsuite/ld-aarch64/farcall-b-gsym.s
new file mode 100644
index 0000000..b7bfe23
--- /dev/null
+++ b/ld/testsuite/ld-aarch64/farcall-b-gsym.s
@@ -0,0 +1,17 @@
+	.global _start
+	.global bar_gsym
+
+# We will place the section .text at 0x1000.
+
+	.text
+
+_start:
+# for long jump (JUMP26) to global symbol, we shouldn't insert veneer
+# as the veneer will clobber IP0/IP1 which is caller saved, gcc only
+# reserve them for function call relocation (CALL26).
+	b bar_gsym
+	# ((1 << 25) - 1) << 2
+	.skip 134217724, 0
+bar_gsym:
+	nop
+	ret
diff --git a/ld/testsuite/ld-aarch64/farcall-b-plt.d b/ld/testsuite/ld-aarch64/farcall-b-plt.d
new file mode 100644
index 0000000..9e2c891
--- /dev/null
+++ b/ld/testsuite/ld-aarch64/farcall-b-plt.d
@@ -0,0 +1,38 @@
+#name: aarch64-farcall-b-plt
+#source: farcall-b-plt.s
+#as:
+#ld: -shared
+#objdump: -dr
+#...
+
+Disassembly of section .plt:
+
+.* <foo@plt-0x20>:
+.*:	a9bf7bf0 	stp	x16, x30, \[sp,#-16\]!
+.*:	90040090 	adrp	x16, 8010000 <__foo_veneer\+.*>
+.*:	f941f611 	ldr	x17, \[x16,#1000\]
+.*:	910fa210 	add	x16, x16, #0x3e8
+.*:	d61f0220 	br	x17
+.*:	d503201f 	nop
+.*:	d503201f 	nop
+.*:	d503201f 	nop
+
+.* <foo@plt>:
+.*:	90040090 	adrp	x16, 8010000 <__foo_veneer\+.*>
+.*:	f941fa11 	ldr	x17, \[x16,#1008\]
+.*:	910fc210 	add	x16, x16, #0x3f0
+.*:	d61f0220 	br	x17
+
+Disassembly of section .text:
+
+.* <_start>:
+	...
+.*:	14000003 	b	80002c8 <__foo_veneer>
+.*:	d65f03c0 	ret
+.*:	14000007 	b	80002e0 <__foo_veneer\+.*>
+
+.* <__foo_veneer>:
+.*:	90fc0010 	adrp	x16, 0 <foo@plt-0x2b0>
+.*:	910ac210 	add	x16, x16, #0x2b0
+.*:	d61f0200 	br	x16
+	...
diff --git a/ld/testsuite/ld-aarch64/farcall-b-plt.s b/ld/testsuite/ld-aarch64/farcall-b-plt.s
new file mode 100644
index 0000000..227f5f1
--- /dev/null
+++ b/ld/testsuite/ld-aarch64/farcall-b-plt.s
@@ -0,0 +1,11 @@
+	.global _start
+	.global foo
+	.type foo, @function
+	.text
+_start:
+	# ((1 << 25) - 1) << 2
+	# jump26 relocation out of range to plt stub,
+	# we need long branch veneer.
+	.skip 134217724, 0
+	b foo
+	ret
diff --git a/ld/testsuite/ld-aarch64/farcall-bl-plt.d b/ld/testsuite/ld-aarch64/farcall-bl-plt.d
new file mode 100644
index 0000000..205a810
--- /dev/null
+++ b/ld/testsuite/ld-aarch64/farcall-bl-plt.d
@@ -0,0 +1,38 @@
+#name: aarch64-farcall-bl-plt
+#source: farcall-bl-plt.s
+#as:
+#ld: -shared
+#objdump: -dr
+#...
+
+Disassembly of section .plt:
+
+.* <foo@plt-0x20>:
+.*:	a9bf7bf0 	stp	x16, x30, \[sp,#-16\]!
+.*:	90040090 	adrp	x16, 8010000 <__foo_veneer\+.*>
+.*:	f941f611 	ldr	x17, \[x16,#1000\]
+.*:	910fa210 	add	x16, x16, #0x3e8
+.*:	d61f0220 	br	x17
+.*:	d503201f 	nop
+.*:	d503201f 	nop
+.*:	d503201f 	nop
+
+.* <foo@plt>:
+.*:	90040090 	adrp	x16, 8010000 <__foo_veneer\+.*>
+.*:	f941fa11 	ldr	x17, \[x16,#1008\]
+.*:	910fc210 	add	x16, x16, #0x3f0
+.*:	d61f0220 	br	x17
+
+Disassembly of section .text:
+
+.* <_start>:
+	...
+.*:	94000003 	bl	80002c8 <__foo_veneer>
+.*:	d65f03c0 	ret
+.*:	14000007 	b	80002e0 <__foo_veneer\+.*>
+
+.* <__foo_veneer>:
+.*:	90fc0010 	adrp	x16, 0 <foo@plt-0x2b0>
+.*:	910ac210 	add	x16, x16, #0x2b0
+.*:	d61f0200 	br	x16
+	...
diff --git a/ld/testsuite/ld-aarch64/farcall-bl-plt.s b/ld/testsuite/ld-aarch64/farcall-bl-plt.s
new file mode 100644
index 0000000..2cb0dd0
--- /dev/null
+++ b/ld/testsuite/ld-aarch64/farcall-bl-plt.s
@@ -0,0 +1,12 @@
+	.global _start
+	.global foo
+	.type foo, @function
+	.text
+
+_start:
+	# ((1 << 25) - 1) << 2
+	# call26 relocation out of range to plt stub,
+	# we need long branch veneer.
+	.skip 134217724, 0
+	bl foo
+	ret

[AArch64] Long branch veneer support far symbol defined by --defsym

[Jiong Wang]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]


Another long branch veneer issue in AArch64 backend is currently we
reject far symbol defined by --defsym when generating long branch
veneer.  This is too strict as according to AArch64 ELF Specification,
symbol with type of non STT_FUNC but in different input section with
relocation place should insert long branch veneer.

To support symbol defined by --defsym, we need to support symbol comes
from ABS section at least.

OK for trunk?

Thanks

2015-07-20  Jiong Wang  <jiong.wang@arm.com>

bfd/
  * bfd/elfnn-aarch64.c (aarch64_type_of_stub): New parameter "sym_sec". 
  Loose the check for symbol from ABS section.
  (elfNN_aarch64_size_stubs): Pass sym_sec.

ld/testsuite/
  * ld-aarch64/farcall-b-defsym.s: New test.
  * ld-aarch64/farcall-bl-defsym.s: Ditto.
  * ld-aarch64/farcall-b-defsym.d: New expectation.
  * ld-aarch64/farcall-bl-defsym.d: Ditto.
-- 
Regards,
Jiong


[-- Attachment #2: diff-sec.patch --]
[-- Type: text/x-diff, Size: 3865 bytes --]

diff --git a/bfd/elfnn-aarch64.c b/bfd/elfnn-aarch64.c
index e05a5da..cfc3ad1 100644
--- a/bfd/elfnn-aarch64.c
+++ b/bfd/elfnn-aarch64.c
@@ -2205,6 +2205,7 @@ static enum elf_aarch64_stub_type
 aarch64_type_of_stub (struct bfd_link_info *info,
 		      asection *input_sec,
 		      const Elf_Internal_Rela *rel,
+		      asection *sym_sec,
 		      unsigned char st_type,
 		      struct elf_aarch64_link_hash_entry *hash,
 		      bfd_vma destination)
@@ -2216,7 +2217,8 @@ aarch64_type_of_stub (struct bfd_link_info *info,
   enum elf_aarch64_stub_type stub_type = aarch64_stub_none;
   bfd_boolean via_plt_p;
 
-  if (st_type != STT_FUNC)
+  if (st_type != STT_FUNC
+      && (sym_sec != bfd_abs_section_ptr))
     return stub_type;
 
   globals = elf_aarch64_hash_table (info);
@@ -3704,7 +3706,7 @@ elfNN_aarch64_size_stubs (bfd *output_bfd,
 
 		  /* Determine what (if any) linker stub is needed.  */
 		  stub_type = aarch64_type_of_stub
-		    (info, section, irela, st_type, hash, destination);
+		    (info, section, irela, sym_sec, st_type, hash, destination);
 		  if (stub_type == aarch64_stub_none)
 		    continue;
 
diff --git a/ld/testsuite/ld-aarch64/aarch64-elf.exp b/ld/testsuite/ld-aarch64/aarch64-elf.exp
index bfbbe24..f3dc51c 100644
--- a/ld/testsuite/ld-aarch64/aarch64-elf.exp
+++ b/ld/testsuite/ld-aarch64/aarch64-elf.exp
@@ -113,6 +113,8 @@ run_dump_test "limit-b"
 run_dump_test "limit-bl"
 run_dump_test "farcall-section"
 run_dump_test "farcall-back"
+run_dump_test "farcall-b-defsym"
+run_dump_test "farcall-bl-defsym"
 run_dump_test "farcall-bl"
 run_dump_test "farcall-b"
 run_dump_test "farcall-b-none-function"
diff --git a/ld/testsuite/ld-aarch64/farcall-b-defsym.d b/ld/testsuite/ld-aarch64/farcall-b-defsym.d
new file mode 100644
index 0000000..c3e1602
--- /dev/null
+++ b/ld/testsuite/ld-aarch64/farcall-b-defsym.d
@@ -0,0 +1,18 @@
+#name: aarch64-farcall-b-defsym
+#source: farcall-b-defsym.s
+#as:
+#ld: -Ttext 0x1000 --defsym=bar=0x8001000
+#objdump: -dr
+#...
+
+Disassembly of section .text:
+
+0000000000001000 <_start>:
+ +1000:	14000003 	b	100c <__bar_veneer>
+ +1004:	d65f03c0 	ret
+[ \t]+1008:[ \t]+14000007[ \t]+b[ \t]+1024 <__bar_veneer\+0x18>
+000000000000100c <__bar_veneer>:
+    100c:	90040010 	adrp	x16, 8001000 <bar>
+    1010:	91000210 	add	x16, x16, #0x0
+    1014:	d61f0200 	br	x16
+	...
diff --git a/ld/testsuite/ld-aarch64/farcall-b-defsym.s b/ld/testsuite/ld-aarch64/farcall-b-defsym.s
new file mode 100644
index 0000000..3eec50c
--- /dev/null
+++ b/ld/testsuite/ld-aarch64/farcall-b-defsym.s
@@ -0,0 +1,10 @@
+	.global _start
+	.global bar
+
+# We will place the section .text at 0x1000.
+
+	.text
+
+_start:
+	b bar
+	ret
diff --git a/ld/testsuite/ld-aarch64/farcall-bl-defsym.d b/ld/testsuite/ld-aarch64/farcall-bl-defsym.d
new file mode 100644
index 0000000..68332bf
--- /dev/null
+++ b/ld/testsuite/ld-aarch64/farcall-bl-defsym.d
@@ -0,0 +1,18 @@
+#name: aarch64-farcall-bl-defsym
+#source: farcall-bl-defsym.s
+#as:
+#ld: -Ttext 0x1000 --defsym=bar=0x8001000
+#objdump: -dr
+#...
+
+Disassembly of section .text:
+
+0000000000001000 <_start>:
+ +1000:	94000003 	bl	100c <__bar_veneer>
+ +1004:	d65f03c0 	ret
+[ \t]+1008:[ \t]+14000007[ \t]+b[ \t]+1024 <__bar_veneer\+0x18>
+000000000000100c <__bar_veneer>:
+    100c:	90040010 	adrp	x16, 8001000 <bar>
+    1010:	91000210 	add	x16, x16, #0x0
+    1014:	d61f0200 	br	x16
+	...
diff --git a/ld/testsuite/ld-aarch64/farcall-bl-defsym.s b/ld/testsuite/ld-aarch64/farcall-bl-defsym.s
new file mode 100644
index 0000000..c525db6
--- /dev/null
+++ b/ld/testsuite/ld-aarch64/farcall-bl-defsym.s
@@ -0,0 +1,10 @@
+	.global _start
+	.global bar
+
+# We will place the section .text at 0x1000.
+
+	.text
+
+_start:
+	bl bar
+	ret

Re: [AArch64] PR18668, Generate long branch veneer if call to plt stub is out of range

[Yao Qi]

Jiong Wang <jiong.wang@arm.com> writes:

> +Disassembly of section .plt:
> +
> +.* <foo@plt-0x20>:
> +.*:	a9bf7bf0 	stp	x16, x30, \[sp,#-16\]!
> +.*:	90040090 	adrp	x16, 8010000 <__foo_veneer\+.*>
> +.*:	f941f611 	ldr	x17, \[x16,#1000\]
> +.*:	910fa210 	add	x16, x16, #0x3e8
> +.*:	d61f0220 	br	x17
> +.*:	d503201f 	nop
> +.*:	d503201f 	nop
> +.*:	d503201f 	nop
> +
> +.* <foo@plt>:
> +.*:	90040090 	adrp	x16, 8010000 <__foo_veneer\+.*>
> +.*:	f941fa11 	ldr	x17, \[x16,#1008\]
> +.*:	910fc210 	add	x16, x16, #0x3f0
> +.*:	d61f0220 	br	x17
> +
> +Disassembly of section .text:
> +
> +.* <_start>:
> +	...
> +.*:	14000003 	b	80002c8 <__foo_veneer>
> +.*:	d65f03c0 	ret
> +.*:	14000007 	b	80002e0 <__foo_veneer\+.*>
> +
> +.* <__foo_veneer>:
> +.*:	90fc0010 	adrp	x16, 0 <foo@plt-0x2b0>
> +.*:	910ac210 	add	x16, x16, #0x2b0
> +.*:	d61f0200 	br	x16

The code like this will confuse GDB on setting up frames when GDB wants
to step into the function foo.  As a result, when we type command "step"
to step into function "foo", GDB stops inferior at somewhere in veneer
by mistake, which is confusing to users.

Once this patch (and other patches similar to this one) go in, we should
tweak GDB frame unwinder to handle them.  For avoid of doubt, I don't
mean to ask you to hack GDB, just for a record.

-- 
Yao (齐尧)

Re: [AArch64] PR18668, Generate long branch veneer if call to plt stub is out of range

[Jiong Wang]

Yao Qi writes:

> Jiong Wang <jiong.wang@arm.com> writes:
>
>> +Disassembly of section .plt:
>> +
>> +.* <foo@plt-0x20>:
>> +.*:	a9bf7bf0 	stp	x16, x30, \[sp,#-16\]!
>> +.*:	90040090 	adrp	x16, 8010000 <__foo_veneer\+.*>
>> +.*:	f941f611 	ldr	x17, \[x16,#1000\]
>> +.*:	910fa210 	add	x16, x16, #0x3e8
>> +.*:	d61f0220 	br	x17
>> +.*:	d503201f 	nop
>> +.*:	d503201f 	nop
>> +.*:	d503201f 	nop
>> +
>> +.* <foo@plt>:
>> +.*:	90040090 	adrp	x16, 8010000 <__foo_veneer\+.*>
>> +.*:	f941fa11 	ldr	x17, \[x16,#1008\]
>> +.*:	910fc210 	add	x16, x16, #0x3f0
>> +.*:	d61f0220 	br	x17
>> +
>> +Disassembly of section .text:
>> +
>> +.* <_start>:
>> +	...
>> +.*:	14000003 	b	80002c8 <__foo_veneer>
>> +.*:	d65f03c0 	ret
>> +.*:	14000007 	b	80002e0 <__foo_veneer\+.*>
>> +
>> +.* <__foo_veneer>:
>> +.*:	90fc0010 	adrp	x16, 0 <foo@plt-0x2b0>
>> +.*:	910ac210 	add	x16, x16, #0x2b0
>> +.*:	d61f0200 	br	x16
>
> The code like this will confuse GDB on setting up frames when GDB wants
> to step into the function foo.  As a result, when we type command "step"
> to step into function "foo", GDB stops inferior at somewhere in veneer
> by mistake, which is confusing to users.
>
> Once this patch (and other patches similar to this one) go in, we should
> tweak GDB frame unwinder to handle them.  For avoid of doubt, I don't
> mean to ask you to hack GDB, just for a record.

Exactly, thanks for paying attention to this.

-- 
Regards,
Jiong

Re: [AArch64] Long branch veneer support far symbol defined by --defsym

[Nick Clifton]

Hi Jiong,

> 2015-07-20  Jiong Wang  <jiong.wang@arm.com>
>
> bfd/
>    * bfd/elfnn-aarch64.c (aarch64_type_of_stub): New parameter "sym_sec".
>    Loose the check for symbol from ABS section.
>    (elfNN_aarch64_size_stubs): Pass sym_sec.
>
> ld/testsuite/
>    * ld-aarch64/farcall-b-defsym.s: New test.
>    * ld-aarch64/farcall-bl-defsym.s: Ditto.
>    * ld-aarch64/farcall-b-defsym.d: New expectation.
>    * ld-aarch64/farcall-bl-defsym.d: Ditto.

Approved - please apply.

Cheers
   Nick

Re: [AArch64] PR18668, Generate long branch veneer if call to plt stub is out of range

[Jiong Wang]

Jiong Wang writes:

> (add the patch)
>
> If text section size is really big, when the linker redirect function
> call to plt stub, the branch offset may be out of range.
>
> Currently, AArch64 BFD has long branch veneer infrastructure ready, but
> it's not enabled for call to plt stub. Only absolute call long branch
> implemented while for PIC/.so, call to PLT stub is the common case and
> we need to support this.
>
> This patch copied some code from ARM32, and cleaned up code logic in
> final_link code where BFD_RELOC_AARCH64_JUMP26/CALL26 handled.
>
> The code logic for handling CALL26/JUMP26 is simplied into:
>
>   * if it call via plt stub, then update relocation value to plt stub address.
>   * use the updated relocation value to check whether it's fit into range.
>     And if the offset don't fit into the range then check whether any
>     long branch veneer register for it.
>   * if long branch veneer register, then udpate final relocation value
>     to the address of veneer, otherwise don't touch relocation value.
>
> test done
> ===
>   native ld check OK.
>   linking the huge OpenLoop reported on PR 18668 successfully which
>   failed on the old bfd linker.
>   
>
> OK for trunk?
>
> 2015-07-15  Jiong Wang  <jiong.wang@arm.com>
> bfd/
>   PR ld/18668
>   * elfnn-aarch64.c (aarch64_type_of_stub): Update destination for
>   calls go through plt stub.
>   (elfNN_aarch64_final_link_relocate): Adjust code logic for CALL26,
>   JUMP26 relocation to support inserting veneer for call to plt stub.
>
> ld/testsuite/
>   * ld-aarch64/farcall-b-gsym.s: New test.
>   * ld-aarch64/farcall-b-plt.s: Ditto.
>   * ld-aarch64/farcall-bl-plt.s: Ditto.
>   * ld-aarch64/farcall-b-gsym.d: New expect file.
>   * ld-aarch64/farcall-b-plt.d: Ditto.
>   * ld-aarch64/farcall-bl-plt.d: Ditto.
>
> OK for trunk?

Ping~

I understand this patch modify some sensitive part of relocation
handling.

But the only functional changes of this patch are

  * in aarch64_type_of_stub, if the branch relocation is plt stub
    related, then we should calculate the distance by

      distance = branch location - PLT stub location

    instead of
    
      distance = branch location - symbol value.

  * "if (h && h->type == STT_FUNC)" in CALL/JMP26 relocation handling
    removed, because it's unncessary.

    if there is no branch stub, then it's not registered in the hash
    table, then the later get_sub_entry will return NULL. we should not
    differenciate local, global and symbol type here, as that should be
    done in stub type check and stub registration.

-- 
Regards,
Jiong

Re: [AArch64] PR18668, Generate long branch veneer if call to plt stub is out of range

[Nick Clifton]

Hi Jiong,

> 2015-07-15  Jiong Wang  <jiong.wang@arm.com>
> bfd/
>    PR ld/18668
>    * elfnn-aarch64.c (aarch64_type_of_stub): Update destination for
>    calls go through plt stub.
>    (elfNN_aarch64_final_link_relocate): Adjust code logic for CALL26,
>    JUMP26 relocation to support inserting veneer for call to plt stub.
>
> ld/testsuite/
>    * ld-aarch64/farcall-b-gsym.s: New test.
>    * ld-aarch64/farcall-b-plt.s: Ditto.
>    * ld-aarch64/farcall-bl-plt.s: Ditto.
>    * ld-aarch64/farcall-b-gsym.d: New expect file.
>    * ld-aarch64/farcall-b-plt.d: Ditto.
>    * ld-aarch64/farcall-bl-plt.d: Ditto.

Approved - please apply - sorry for the long delay in reviewing this patch.

Cheers
   Nick

Re: [AArch64] PR18668, Generate long branch veneer if call to plt stub is out of range

[Jiong Wang]

Nick Clifton writes:

> Hi Jiong,
>
>> 2015-07-15  Jiong Wang  <jiong.wang@arm.com>
>> bfd/
>>    PR ld/18668
>>    * elfnn-aarch64.c (aarch64_type_of_stub): Update destination for
>>    calls go through plt stub.
>>    (elfNN_aarch64_final_link_relocate): Adjust code logic for CALL26,
>>    JUMP26 relocation to support inserting veneer for call to plt stub.
>>
>> ld/testsuite/
>>    * ld-aarch64/farcall-b-gsym.s: New test.
>>    * ld-aarch64/farcall-b-plt.s: Ditto.
>>    * ld-aarch64/farcall-bl-plt.s: Ditto.
>>    * ld-aarch64/farcall-b-gsym.d: New expect file.
>>    * ld-aarch64/farcall-b-plt.d: Ditto.
>>    * ld-aarch64/farcall-bl-plt.d: Ditto.
>
> Approved - please apply - sorry for the long delay in reviewing this
> patch.

  That's fine. Thanks for the review.
  
-- 
Regards,
Jiong