binutils-gdb/ld/testsuite/ld-pe/pr26659-weak-undef-sym.d

26 lines
1.2 KiB
D
Raw Normal View History

PE/Windows x86_64: Fix weak undef symbols after image base change The change in PR19011 changed the image load address from being in the lower 32-bit address space to the higher 64-bit address space. However when you have a weak undef symbol which stays undef at the end of linking the linker has to resolve this (Windows loader does not support undef symbols). As such typically these would resolve to 0. The relocation used for these weak symbols are the normal 32-bit PC_REL call relocs. So when doing the overflow check LD checks if the distance between the symbol and the call is within range. However now that the load address is > 32-bits and the symbol val is 0 this overflow check will always fail. As such the linker gives a bogus error. This patch makes the linker not emit the overflow failure but chooses to still let the check be performed (as it's mid-end code). One down side of this is that it does break the common convention that the call be to sym at 0x0. i.e. before you'd get 401015: 74 05 je 40101c 401017: e8 e4 ef bf ff callq 0 and now you get 140001015: 74 05 je 14000101c 140001017: e8 e4 ef ff bf call 100000000 since the call is PC_REL there's no way to get the range large enough to resolve to 0. As such I have chosen to leave it as the furthest simple range that we can still represent. By only ignoring the error we leave the symbol value itself to still be 0 such that the if(<symbol>) checks still work correctly. bfd/ChangeLog: 2021-04-01 Tamar Christina <tamar.christina@arm.com> PR ld/26659 * cofflink.c (_bfd_coff_generic_relocate_section): Ignore overflow. ld/ChangeLog: 2021-04-01 Tamar Christina <tamar.christina@arm.com> PR ld/26659 * testsuite/ld-pe/pe.exp: Add test. * testsuite/ld-pe/pr26659-weak-undef-sym.d: New test. * testsuite/ld-pe/pr26659-weak-undef-sym.s: New test.
2021-04-02 00:10:38 +08:00
#source: pr26659-weak-undef-sym.s
#target: x86_64-*-cygwin* x86_64-*-pe x86_64-*-mingw*
#ld: -e0
#objdump: -d
#...
00000001[04]0[04]01000 <foo>:
*[0-9a-f]+: 55 push %rbp
*[0-9a-f]+: 48 89 e5 mov %rsp,%rbp
*[0-9a-f]+: 48 83 ec 20 sub \$0x20,%rsp
*[0-9a-f]+: 89 4d 10 mov %ecx,0x10\(%rbp\)
*[0-9a-f]+: 48 8b 05 ee 0f 00 00 mov 0xfee\(%rip\),%rax # [0-9a-f]+ <__data_end__>
*[0-9a-f]+: 48 85 c0 test %rax,%rax
*[0-9a-f]+: 74 05 je [0-9a-f]+ <foo\+0x1c>
*[0-9a-f]+: e8 e4 ef [fb]f [fb]f call 100000000 <__size_of_stack_reserve__\+0xffe00000>
*[0-9a-f]+: 48 8b 05 ed 0f 00 00 mov 0xfed\(%rip\),%rax # [0-9a-f]+ <.refptr.bar2>
*[0-9a-f]+: 48 85 c0 test %rax,%rax
*[0-9a-f]+: 74 05 je [0-9a-f]+ <foo\+0x2d>
*[0-9a-f]+: e8 d3 ef [fb]f [fb]f call 100000000 <__size_of_stack_reserve__\+0xffe00000>
*[0-9a-f]+: 8b 45 10 mov 0x10\(%rbp\),%eax
*[0-9a-f]+: 0f af c0 imul %eax,%eax
*[0-9a-f]+: 48 83 c4 20 add \$0x20,%rsp
*[0-9a-f]+: 5d pop %rbp
*[0-9a-f]+: c3 ret *
PE/Windows x86_64: Fix weak undef symbols after image base change The change in PR19011 changed the image load address from being in the lower 32-bit address space to the higher 64-bit address space. However when you have a weak undef symbol which stays undef at the end of linking the linker has to resolve this (Windows loader does not support undef symbols). As such typically these would resolve to 0. The relocation used for these weak symbols are the normal 32-bit PC_REL call relocs. So when doing the overflow check LD checks if the distance between the symbol and the call is within range. However now that the load address is > 32-bits and the symbol val is 0 this overflow check will always fail. As such the linker gives a bogus error. This patch makes the linker not emit the overflow failure but chooses to still let the check be performed (as it's mid-end code). One down side of this is that it does break the common convention that the call be to sym at 0x0. i.e. before you'd get 401015: 74 05 je 40101c 401017: e8 e4 ef bf ff callq 0 and now you get 140001015: 74 05 je 14000101c 140001017: e8 e4 ef ff bf call 100000000 since the call is PC_REL there's no way to get the range large enough to resolve to 0. As such I have chosen to leave it as the furthest simple range that we can still represent. By only ignoring the error we leave the symbol value itself to still be 0 such that the if(<symbol>) checks still work correctly. bfd/ChangeLog: 2021-04-01 Tamar Christina <tamar.christina@arm.com> PR ld/26659 * cofflink.c (_bfd_coff_generic_relocate_section): Ignore overflow. ld/ChangeLog: 2021-04-01 Tamar Christina <tamar.christina@arm.com> PR ld/26659 * testsuite/ld-pe/pe.exp: Add test. * testsuite/ld-pe/pr26659-weak-undef-sym.d: New test. * testsuite/ld-pe/pr26659-weak-undef-sym.s: New test.
2021-04-02 00:10:38 +08:00
#pass