Correct ld-pe/aarch64.d test output

[Alan Modra]

"foo" is at 0x2010.  This corrects the expected output for .long and
.word referencing foo, showing a problem with relocation handling.

Mark, the relocation special functions you added look like they only
work for gas.  They are also used by the linker when linking to
another output format (which may not be supported by aarch64), and by
objdump, eg. gas/testsuite/gas/aarch64/inst-directive.  I've been
poking at them over the last few days, and realized I don't know
enough about what exactly goes into the addend fields stored in
aarch64-pe relocatable object files to be able to fix the problems.
Is is really a sensible addend with no symbol value confounding?
Someone with access to existing aarch64-pe assemblers and linkers will
need to do some digging, particularly in the case where a relocation
is emitted against defined symbols like "foo" in ld-pe/aarch64a.s.

I've also been looking again at bfd_perform_relocation and
bfd_install_relocation.  These functions grew the way they are to be
compatible with old COFF and AOUT object file formats emitted by other
linkers, and no one has been game to remove the hacks.  One
possibility that I may look into implementing is a flag in the reloc
howto that asks for sane behaviour.

	* testsuite/ld-pe/aarch64.d: Correct expected output.

diff --git a/ld/testsuite/ld-pe/aarch64.d b/ld/testsuite/ld-pe/aarch64.d
index cc3daf9e9cd..eea52e10fe2 100644
--- a/ld/testsuite/ld-pe/aarch64.d
+++ b/ld/testsuite/ld-pe/aarch64.d
@@ -10,41 +10,41 @@ Disassembly of section .text:
 0000000000002010 <foo>:
     2010:	12345678 	and	w24, w19, #0xfffff003
     2014:	12345678 	and	w24, w19, #0xfffff003
-    2018:	00002000 	udf	#8192
-    201c:	00002000 	udf	#8192
+    2018:	00002010 	udf	#8208
+    201c:	00002010 	udf	#8208
     2020:	00002220 	udf	#8736
     2024:	00002220 	udf	#8736
-    2028:	00002001 	udf	#8193
-    202c:	00002001 	udf	#8193
+    2028:	00002011 	udf	#8209
+    202c:	00002011 	udf	#8209
     2030:	00002221 	udf	#8737
     2034:	00002221 	udf	#8737
-    2038:	00001fff 	udf	#8191
-    203c:	00001fff 	udf	#8191
+    2038:	0000200f 	udf	#8207
+    203c:	0000200f 	udf	#8207
     2040:	0000221f 	udf	#8735
     2044:	0000221f 	udf	#8735
     2048:	9abcdef0 	.inst	0x9abcdef0 ; undefined
     204c:	12345678 	and	w24, w19, #0xfffff003
     2050:	9abcdef0 	.inst	0x9abcdef0 ; undefined
     2054:	12345678 	and	w24, w19, #0xfffff003
-    2058:	00002000 	udf	#8192
+    2058:	00002010 	udf	#8208
     205c:	00000000 	udf	#0
-    2060:	00002000 	udf	#8192
+    2060:	00002010 	udf	#8208
     2064:	00000000 	udf	#0
     2068:	00002220 	udf	#8736
     206c:	00000000 	udf	#0
     2070:	00002220 	udf	#8736
     2074:	00000000 	udf	#0
-    2078:	00002001 	udf	#8193
+    2078:	00002011 	udf	#8209
     207c:	00000000 	udf	#0
-    2080:	00002001 	udf	#8193
+    2080:	00002011 	udf	#8209
     2084:	00000000 	udf	#0
     2088:	00002221 	udf	#8737
     208c:	00000000 	udf	#0
     2090:	00002221 	udf	#8737
     2094:	00000000 	udf	#0
-    2098:	00001fff 	udf	#8191
+    2098:	0000200f 	udf	#8207
     209c:	00000000 	udf	#0
-    20a0:	00001fff 	udf	#8191
+    20a0:	0000200f 	udf	#8207
     20a4:	00000000 	udf	#0
     20a8:	0000221f 	udf	#8735
     20ac:	00000000 	udf	#0

-- 
Alan Modra
Australia Development Lab, IBM