[Bug ld/22903] [AArch64] Insufficient veneer stub alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=22903 Jeremi changed: What|Removed |Added CC||jeremip11 at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22903] [AArch64] Insufficient veneer stub alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=22903 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Nick Clifton --- Well a working patch is definitely preferable to a broken one. So I have tweaked your patch so that it applies, added the NOP definitions to the AArch64 emulparam files, and checked the result in. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22903] [AArch64] Insufficient veneer stub alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=22903
--- Comment #8 from cvs-commit at gcc dot gnu.org ---
The master branch has been updated by Nick Clifton :
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9a2ebffd4dd9cffac395177e997f6f47408b4782
commit 9a2ebffd4dd9cffac395177e997f6f47408b4782
Author: Jim Wilson
Date: Fri Mar 2 10:47:25 2018 +
Ensure 8-byte alignment for AArch64 stubs.
PR 22903
bfd * elfnn-aarch64.c (_bfd_aarch64_resize_stubs): Add 8 bytes for branch
and nop instead of 4.
(elfNN_arch64_build_stubs): Add nop after branch. Increase size by
8 instead of 4.
ld * emultempl/aarch64elf.em (elf${ELFSIZE}_aarch64_add_stub_section):
Give stub_sec 8 byte alignment.
* emulparams/aarch64cloudabi.sh (NOP): Set to 0x1f2003d5.
* emulparams/aarch64elf.sh (NOP): Likewise.
* emulparams/aarch64elf32.sh (NOP): Likewise.
* emulparams/aarch64fbsd.sh (NOP): Likewise.
* emulparams/aarch64linux.sh (NOP): Likewise.
* emulparams/aarch64linux32.sh (NOP): Likewise.
* testsuite/ld-aarch64/erratum835769.d: Adjust for added nop.
* testsuite/ld-aarch64/erratum843419.d: Likewise.
* testsuite/ld-aarch64/farcall-b-defsym.d: Likewise.
* testsuite/ld-aarch64/farcall-b-none-function.d: Likewise.
* testsuite/ld-aarch64/farcall-b-plt.d: Likewise.
* testsuite/ld-aarch64/farcall-b-section.d: Likewise.
* testsuite/ld-aarch64/farcall-b.d: Likewise.
* testsuite/ld-aarch64/farcall-back.d: Likewise.
* testsuite/ld-aarch64/farcall-bl-defsym.d: Likewise.
* testsuite/ld-aarch64/farcall-bl-none-function.d: Likewise.
* testsuite/ld-aarch64/farcall-bl-plt.d: Likewise.
* testsuite/ld-aarch64/farcall-bl-section.d: Likewise.
* testsuite/ld-aarch64/farcall-bl.d: Likewise.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22903] [AArch64] Insufficient veneer stub alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=22903 --- Comment #7 from Jim Wilson --- I don't particularly care how this gets fixed. Your patch seems to have a flaw. You are skipping over the first 4 bytes of the stub if it isn't aligned, but you aren't increasing the size of the stub to allow for alignment padding, which means you end up writing past the allocated area. You can see the problem with the testcase the original poster put in this PR. The first stub has its last word overwritten by the nop emitted for the second stub, and the second stub has its last word chopped off. My patch seems a little cleaner, as it just adds a nop to ensure that the first stub is aligned. The only problem I know of with my patch is that we can get zero bytes added at the end of the text section sometimes, which prevents the branch Marcus added at the start of the stub section from working as intended. That can be seen in the testcase in this bug report, where 0x100c is a 0. I tried your suggestion of setting NOP in ld/emulparams/aarch64elf.sh, that does work, except I needed to add NOP=0x1f2003d5 and I needed to add it to the aarch64linux.sh file. Probably every *aarch64*.sh file needs to be fixed. My patch unfortunately does not apply as is, as some of the linker testcase *.d files have been modified since I originally wrote my patch. It doesn't look too hard to fix though. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22903] [AArch64] Insufficient veneer stub alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=22903 --- Comment #6 from Pekka Seppänen --- Created attachment 10864 --> https://sourceware.org/bugzilla/attachment.cgi?id=10864&action=edit Makefile for the testcase really, it just compiles the assembly code and links with `--section-start .foo=0xff' -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22903] [AArch64] Insufficient veneer stub alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=22903 --- Comment #4 from Pekka Seppänen --- Hi. My apologies for not noticing the branch between the sections; I was not aware of it even one was just in front of my eyes (it was right after a lenghty data table, and objdump considered the branch bytecode as data). I was also talking nonsense about the -fpic and -fpie, and they do not obviously have anything to do with this (as the limiting factor is simply the maximum branch +-128M reach) -- an another issue was haunting my mind and I accidentally mixed things up. Anyway, I tried the Nick's patch, but unfortunately it does not work: If the offsetted branch address crosses 32/64-bit boundary, things will go horribly wrong: the upper half is either replaced by a nop bytecode or left out, and the branch takes a fatal dive to the unknow. If I revert back to a week or so old GCC and binutils 2.30, the addresses are again valid. This very unfortunate effect can be actually seen in the testcase, that the patch modifies. 1000 <_start>: [ ... ] 100c: 140db 1040 <__bar_veneer+0x14> 1010: d503201fnop 1014 <__bar2_veneer>: 1014: 5890ldr x16, 1024 <__bar2_veneer+0x10> 1018: 1011adr x17, 1018 <__bar2_veneer+0x4> 101c: 8b110210add x16, x16, x17 1020: d61f0200br x16 1024: efec.word 0xefec 1028: d503201f.word 0xd503201f # <-- should be 0x00fe 102c <__bar_veneer>: 102c: 5890ldr x16, 103c <__bar_veneer+0x10> 1030: 1011adr x17, 1030 <__bar_veneer+0x4> 1034: 8b110210add x16, x16, x17 1038: d61f0200br x16 103c: efd0.word 0xefd0 # <-- should have .word 0x00fe, and not just left out. (Testcase attached, I used the latest GCC and binutils-gdb trunk.) Seeing the complexity hiding in the little details, I guess I'll just rework my approach so that there'll be no veneering necessary. Maybe the best thing to do would be to create a new directive, that would allow user to place the stubs at a convenient location (like .ltorg) and perhaps specify the filler, unless the default is suitable. I have no doubt that someone is exploiting the de facto that codeflow should be contiguous between sections, so I guess the default case for the branches over stubs have to stay. When dealing with a highly space limited target it is useful, while obviously a bit dangerous, to let the linker fill the gaps between data and code structures that are somewhat small, but have a large alignment constraints (MMU, exception tables etc.). In that case all such branching is, if not harmful, just wasted space. I could not also think of any case where the excution would land back to the section branch. The only case I could figure, would have to be some sort of terrible hack (say, the section branch would occur at a stage N translation border, and e.g. for that particular page Access Flag would be unset), where an exception handing code would do something magic, and then return to the next instruction. In that case doing a nop and branch (instead of branch and nop) would do the trick, but obviously that is only one of the possible combinations and therefore just a solution to a problem, that really does not exist (or should ever exist, if you ask me). -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22903] [AArch64] Insufficient veneer stub alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=22903 --- Comment #5 from Pekka Seppänen --- Created attachment 10863 --> https://sourceware.org/bugzilla/attachment.cgi?id=10863&action=edit Long braches crossing the 32/64-bit boundary -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22903] [AArch64] Insufficient veneer stub alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=22903 --- Comment #3 from Nick Clifton --- (In reply to Jim Wilson from comment #2) > See the related > https://sourceware.org/ml/binutils/2016-06/msg00021.html > which was never resolved. Hi Jim, I am sorry that that patch was never resolved. It certainly would have fixed this PR. Do you have a preference for which patch we should use to solve this issue ? I like mine because it does not change the alignment of the stub section, so there should be no problems with holes between a stub section and a real code section[1]. On the other hand your patch wastes less space as it does not insert nops between stubs, so overall the stub sections will be smaller. I am happy to go with either solution, so please let me know your thoughts. Cheers Nick [1]: It seems strange to me that ld/emulparams/aarch64elf.sh sets the NOP variable to 0 rather than 0xd503201f. If it used the latter value then spaces between code sections would be filled with nop instructions which would make the gap problem go away. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22903] [AArch64] Insufficient veneer stub alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=22903 Jim Wilson changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #2 from Jim Wilson --- See the related https://sourceware.org/ml/binutils/2016-06/msg00021.html which was never resolved. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22903] [AArch64] Insufficient veneer stub alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=22903 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Created attachment 10861 --> https://sourceware.org/bugzilla/attachment.cgi?id=10861&action=edit Proposed patch Hi Pekka, This patch should take care of the problem, but please give it a test yourself just to confirm. I am not going to apply the patch just yet however, as I would like to see if anyone has any has any objections to the increase in the size of the long branch stubs. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
