binutils-gdb/ld/testsuite/ld-aarch64/erratum843419_tls_ie.d

50 lines
1.5 KiB
D
Raw Normal View History

AArch64: Fix regression in Cortex A53 erratum when PIE. (PR ld/23904) The fix for PR ld/22263 causes TLS relocations using ADRP to be relaxed into MOVZ, however this causes issues for the erratum code. The erratum code scans the input sections looking for ADRP instructions and notes their location in the stream. It then later tries to find them again in order to generate the linker stubs. Due to the relaxation it instead finds a MOVZ and hard aborts. Since this relaxation is a valid one, and in which case the erratum no longer applies, it shouldn't abort but instead just continue. This changes the TLS relaxation code such that when it finds an ADRP and it relaxes it, it removes the erratum entry from the work list by changing the stub type into none so the stub is ignored. The entry is not actually removed as removal is a more expensive operation and we have already allocated the memory anyway. The clearing is done for IE->LE and GD->LE relaxations, and a testcase is added for the IE case. The GD case I believe to be impossible to get together with the erratum sequence due to the required BL which would break the sequence. However to cover all basis I have added the guard there as well. build on native hardware and regtested on aarch64-none-elf, aarch64-none-elf (32 bit host), aarch64-none-linux-gnu, aarch64-none-linux-gnu (32 bit host) Cross-compiled and regtested on aarch64-none-linux-gnu, aarch64_be-none-linux-gnu Testcase in PR23940 tested and works as expected now and benchmarks ran on A53 showing no regressions and no issues. bfd/ChangeLog: PR ld/23904 * elfnn-aarch64.c (_bfd_aarch64_adrp_p): Use existing constants. (_bfd_aarch64_erratum_843419_branch_to_stub): Use _bfd_aarch64_adrp_p. (struct erratum_835769_branch_to_stub_clear_data): New. (_bfd_aarch64_erratum_843419_clear_stub): New. (clear_erratum_843419_entry): New. (elfNN_aarch64_tls_relax): Use it. (elfNN_aarch64_relocate_section): Pass input_section. (aarch64_map_one_stub): Handle branch type none as valid. ld/ChangeLog: PR ld/23904 * testsuite/ld-aarch64/aarch64-elf.exp: Add erratum843419_tls_ie. * testsuite/ld-aarch64/erratum843419_tls_ie.d: New test. * testsuite/ld-aarch64/erratum843419_tls_ie.s: New test.
2018-11-27 20:33:21 +08:00
#source: erratum843419_tls_ie.s
#as:
#ld: --fix-cortex-a53-843419 -e0 --section-start .e843419=0x20000000 -Ttext=0x400000 -Tdata=0x40000000
#objdump: -dr
#...
Disassembly of section .e843419:
0*20000000 <farbranch>:
[ ]*20000000: d10043ff sub sp, sp, #0x10
[ ]*20000004: d28001a7 mov x7, #0xd // #13
[ ]*20000008: b9000fe7 str w7, \[sp, #12\]
[ ]*2000000c: 140003fb b 20000ff8 <e843419>
...
0*20000ff8 <e843419>:
[ ]*20000ff8: d2a00000 movz x0, #0x0, lsl #16
[ ]*20000ffc: f800c007 stur x7, \[x0, #12\]
[ ]*20001000: d2800128 mov x8, #0x9 // #9
[ ]*20001004: f2800208 movk x8, #0x10
[ ]*20001008: 8b050020 add x0, x1, x5
[ ]*2000100c: b9400fe7 ldr w7, \[sp, #12\]
[ ]*20001010: 0b0700e0 add w0, w7, w7
[ ]*20001014: 910043ff add sp, sp, #0x10
[ ]*20001018: d65f03c0 ret
[ ]*2000101c: 00000000 udf #0
AArch64: Fix regression in Cortex A53 erratum when PIE. (PR ld/23904) The fix for PR ld/22263 causes TLS relocations using ADRP to be relaxed into MOVZ, however this causes issues for the erratum code. The erratum code scans the input sections looking for ADRP instructions and notes their location in the stream. It then later tries to find them again in order to generate the linker stubs. Due to the relaxation it instead finds a MOVZ and hard aborts. Since this relaxation is a valid one, and in which case the erratum no longer applies, it shouldn't abort but instead just continue. This changes the TLS relaxation code such that when it finds an ADRP and it relaxes it, it removes the erratum entry from the work list by changing the stub type into none so the stub is ignored. The entry is not actually removed as removal is a more expensive operation and we have already allocated the memory anyway. The clearing is done for IE->LE and GD->LE relaxations, and a testcase is added for the IE case. The GD case I believe to be impossible to get together with the erratum sequence due to the required BL which would break the sequence. However to cover all basis I have added the guard there as well. build on native hardware and regtested on aarch64-none-elf, aarch64-none-elf (32 bit host), aarch64-none-linux-gnu, aarch64-none-linux-gnu (32 bit host) Cross-compiled and regtested on aarch64-none-linux-gnu, aarch64_be-none-linux-gnu Testcase in PR23940 tested and works as expected now and benchmarks ran on A53 showing no regressions and no issues. bfd/ChangeLog: PR ld/23904 * elfnn-aarch64.c (_bfd_aarch64_adrp_p): Use existing constants. (_bfd_aarch64_erratum_843419_branch_to_stub): Use _bfd_aarch64_adrp_p. (struct erratum_835769_branch_to_stub_clear_data): New. (_bfd_aarch64_erratum_843419_clear_stub): New. (clear_erratum_843419_entry): New. (elfNN_aarch64_tls_relax): Use it. (elfNN_aarch64_relocate_section): Pass input_section. (aarch64_map_one_stub): Handle branch type none as valid. ld/ChangeLog: PR ld/23904 * testsuite/ld-aarch64/aarch64-elf.exp: Add erratum843419_tls_ie. * testsuite/ld-aarch64/erratum843419_tls_ie.d: New test. * testsuite/ld-aarch64/erratum843419_tls_ie.s: New test.
2018-11-27 20:33:21 +08:00
[ ]*20001020: 14000400 b 20002020 <e843419\+0x1028>
[ ]*20001024: d503201f nop
[ ]*20001028: 00000000 udf #0
AArch64: Fix regression in Cortex A53 erratum when PIE. (PR ld/23904) The fix for PR ld/22263 causes TLS relocations using ADRP to be relaxed into MOVZ, however this causes issues for the erratum code. The erratum code scans the input sections looking for ADRP instructions and notes their location in the stream. It then later tries to find them again in order to generate the linker stubs. Due to the relaxation it instead finds a MOVZ and hard aborts. Since this relaxation is a valid one, and in which case the erratum no longer applies, it shouldn't abort but instead just continue. This changes the TLS relaxation code such that when it finds an ADRP and it relaxes it, it removes the erratum entry from the work list by changing the stub type into none so the stub is ignored. The entry is not actually removed as removal is a more expensive operation and we have already allocated the memory anyway. The clearing is done for IE->LE and GD->LE relaxations, and a testcase is added for the IE case. The GD case I believe to be impossible to get together with the erratum sequence due to the required BL which would break the sequence. However to cover all basis I have added the guard there as well. build on native hardware and regtested on aarch64-none-elf, aarch64-none-elf (32 bit host), aarch64-none-linux-gnu, aarch64-none-linux-gnu (32 bit host) Cross-compiled and regtested on aarch64-none-linux-gnu, aarch64_be-none-linux-gnu Testcase in PR23940 tested and works as expected now and benchmarks ran on A53 showing no regressions and no issues. bfd/ChangeLog: PR ld/23904 * elfnn-aarch64.c (_bfd_aarch64_adrp_p): Use existing constants. (_bfd_aarch64_erratum_843419_branch_to_stub): Use _bfd_aarch64_adrp_p. (struct erratum_835769_branch_to_stub_clear_data): New. (_bfd_aarch64_erratum_843419_clear_stub): New. (clear_erratum_843419_entry): New. (elfNN_aarch64_tls_relax): Use it. (elfNN_aarch64_relocate_section): Pass input_section. (aarch64_map_one_stub): Handle branch type none as valid. ld/ChangeLog: PR ld/23904 * testsuite/ld-aarch64/aarch64-elf.exp: Add erratum843419_tls_ie. * testsuite/ld-aarch64/erratum843419_tls_ie.d: New test. * testsuite/ld-aarch64/erratum843419_tls_ie.s: New test.
2018-11-27 20:33:21 +08:00
[ ]*2000102c: 17fffff7 b 20001008 <e843419\+0x10>
...
Disassembly of section .text:
0*400000 <main>:
[ ]*400000: d10043ff sub sp, sp, #0x10
[ ]*400004: d28001a7 mov x7, #0xd // #13
[ ]*400008: b9000fe7 str w7, \[sp, #12\]
[ ]*40000c: 14000005 b 400020 <__farbranch_veneer>
[ ]*400010: d65f03c0 ret
[ ]*400014: d503201f nop
[ ]*400018: 14000400 b 401018 <__farbranch_veneer\+0xff8>
[ ]*40001c: d503201f nop
0*400020 <__farbranch_veneer>:
[ ]*400020: 900fe010 adrp x16, 20000000 <farbranch>
[ ]*400024: 91000210 add x16, x16, #0x0
[ ]*400028: d61f0200 br x16
...