[Bug binutils/22880] ./configure stalls forever if CC=clang
https://sourceware.org/bugzilla/show_bug.cgi?id=22880 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Nick Clifton --- (In reply to Bjorn Pagen from comment #2) Hi Bjorn, > I used clang-5.0.1: OK - so that explains why we are seeing different results. But I also think that it conforms my theory that this is a clang bug and not a binutils bug. So it really ought to be reported there. I should also note that configure code in question comes from the config/acx.m4 file which is actually part of gcc. The binutils project makes use of it, but the gcc project is the official owner of the file. 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
[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 --- 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 #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 #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 binutils/22905] integer overflow in display_debug_ranges
https://sourceware.org/bugzilla/show_bug.cgi?id=22905 --- Comment #1 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=d11ae95ea3403559f052903ab053f43ad7821e37 commit d11ae95ea3403559f052903ab053f43ad7821e37 Author: Nick Clifton Date: Thu Mar 1 16:14:08 2018 + Prevent illegal memory accesses triggerd by intger overflow when parsing corrupt DWARF information on a 32-bit host. PR 22905 * dwarf.c (display_debug_ranges): Check that the offset loaded from the range_entry structure is valid. -- 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 binutils/22905] integer overflow in display_debug_ranges
https://sourceware.org/bugzilla/show_bug.cgi?id=22905 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Hi Skysider, Thanks for reporting this bug. I have checked in a small patch to add a check for an integer overflow at the point you indicated. 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
[Bug binutils/22880] ./configure stalls forever if CC=clang
https://sourceware.org/bugzilla/show_bug.cgi?id=22880 --- Comment #4 from H.J. Lu --- FWIW, I used clang 5.0.1 on Fedora 27 to build binutils master branch. -- 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 binutils/22880] ./configure stalls forever if CC=clang
https://sourceware.org/bugzilla/show_bug.cgi?id=22880 --- Comment #5 from Bjorn Pagen --- (In reply to H.J. Lu from comment #4) > FWIW, I used clang 5.0.1 on Fedora 27 to build binutils master branch. That's good to hear. Hopefully that sticks around long enough to be in 2.31. -- 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/22909] New: Expand --warn-shared-textrel support to all executables, not only PIC objects
https://sourceware.org/bugzilla/show_bug.cgi?id=22909 Bug ID: 22909 Summary: Expand --warn-shared-textrel support to all executables, not only PIC objects Product: binutils Version: 2.30 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: slyfox at inbox dot ru Target Milestone: --- Gentoo enables --warn-shared-textrel by default for and extends warning to all dynamic executables (PIE or not): https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/binutils/2.17/66_all_binutils-2.17.50.0.2-warn-textrel.patch?revision=1.1&view=markup What do you think of extending this option (or adding new one) to cover executables in upstream binutils? Something like --warn-textrel. Lack of TEXTREL warning came up recently in gcc where gcc was built with TEXTRELs due to a platform-specific gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84553 The warning would be complementary to '-Wl,-z,-text' which converts problems of this kind to errors. Related bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20824 : "enable warn-shared-textrel by default". -- 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/22756] Linker relaxation miscalculates symbol addresses on riscv
https://sourceware.org/bugzilla/show_bug.cgi?id=22756 --- Comment #5 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Jim Wilson : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=788af978df01c3667be99a1607b774f5fa844113 commit 788af978df01c3667be99a1607b774f5fa844113 Author: Jim Wilson Date: Thu Mar 1 14:17:57 2018 -0800 RISC-V: Fix symbol size bug when relaxation deletes bytes. bfd/ PR 22756 * elfnn-riscv.c (riscv_relax_delete_bytes): When adjust st_size, use else if instead of if. -- 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 binutils/22880] ./configure stalls forever if CC=clang
https://sourceware.org/bugzilla/show_bug.cgi?id=22880 --- Comment #6 from H.J. Lu --- (In reply to Bjorn Pagen from comment #5) > (In reply to H.J. Lu from comment #4) > > FWIW, I used clang 5.0.1 on Fedora 27 to build binutils master branch. > > That's good to hear. Hopefully that sticks around long enough to be in 2.31. I also built binutils 2.30 with clang 5.0.1 on Fedora 27. -- 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 binutils/22880] ./configure stalls forever if CC=clang
https://sourceware.org/bugzilla/show_bug.cgi?id=22880 --- Comment #7 from Bjorn Pagen --- (In reply to H.J. Lu from comment #6) > (In reply to Bjorn Pagen from comment #5) > > (In reply to H.J. Lu from comment #4) > > > FWIW, I used clang 5.0.1 on Fedora 27 to build binutils master branch. > > > > That's good to hear. Hopefully that sticks around long enough to be in 2.31. > > I also built binutils 2.30 with clang 5.0.1 on Fedora 27. Oh, I guess I'm screwed then. Thanks for all the help anyways :) FWIW I do have a pretty odd software stack, with musl libc, libc++/libc++abi, LLVM/clang, and no gcc whatsoever, and I do not have gnuconfig installed. I also am on gentoo, so it might just be some odd USE flag behavior. -- 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
