[Bug ld/20737] [aarch64] -static -pie linked binary has R_AARCH64_ABS64 relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=20737 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Jiong Wang : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ac33b731d214d79738ca04d27f7464d4482f6a01 commit ac33b731d214d79738ca04d27f7464d4482f6a01 Author: Jiong Wang Date: Thu Nov 10 09:25:17 2016 + [AArch64] Bind defined symbol locally in PIE bfd/ PR target/20737 * elfnn-aarch64.c (elfNN_aarch64_final_link_relocate): Bind defined symbol locally in PIE. ld/ * testsuite/ld-aarch64/pie-bind-locally-a.s: New test source. * testsuite/ld-aarch64/pie-bind-locally-b.s: Likewise. * testsuite/ld-aarch64/pie-bind-locally.d: New testcase. * testsuite/ld-aarch64/aarch64-elf.exp: Run new testcase. -- 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/20737] [aarch64] -static -pie linked binary has R_AARCH64_ABS64 relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=20737 Jiong Wang changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-11-10 Ever confirmed|0 |1 --- Comment #3 from Jiong Wang --- Fix on AArch64, I will post a follow up ARM fix later. -- 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/20737] [aarch64] -static -pie linked binary has R_AARCH64_ABS64 relocation
https://sourceware.org/bugzilla/show_bug.cgi?id=20737 --- Comment #4 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=a18590c38657a982f8d544f2f54f39ba9abe9fca commit a18590c38657a982f8d544f2f54f39ba9abe9fca Author: Nick Clifton Date: Thu Nov 10 12:26:53 2016 + Provide a more helpful error message when the BFD library is unable to load an extremely large section. PR target/20737 * elfnn-aarch64.c (elfNN_aarch64_final_link_relocate): Bind defined symbol locally in PIE. -- 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/20801] objdump memory exhausted when trying to malloc
https://sourceware.org/bugzilla/show_bug.cgi?id=20801 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Hi Joseph, Thanks for reporting this. Objdump is in fact correct - memory is being exhausted. The .note.gnu.build-id section in your test file has a size of 0x800024, which is the cause of the problem. I have checked in a patch however, to add an extra error message to objdump's output, which I hope will make things clearer: objdump: error: id_00,sig_06,src_00,op_flip1,pos_4428(.note.gnu.build-id) is too large (0x800024 bytes) objdump: id_00,sig_06,src_00,op_flip1,pos_4428: Memory exhausted 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 gas/20744] [PPC] Incorrect relocation for VLE-instructions
https://sourceware.org/bugzilla/show_bug.cgi?id=20744 --- Comment #2 from Vladimir Vishniakov --- FYI I've tested other toolchains: Code Warrior and High Tec (gnu-based). They process such relocs in accordance with the documentation. However Code Warrior's assembler generates their own undocumented relocs (e.g. it uses type 0x33 instead of 0xDF for R_PPC_VLE_HA16A). But linker processes well and the standard relocs. -+---+---+---+ as\ld|GNU|CW |HT | -+---+---+---+ GNU |OK |BAD|BAD| -+---+---+---+ CW |N/L|OK |N/L| -+---+---+---+ HT |BAD|OK |OK | -+---+---+---+ N/L not linked due the unknown relocation -- 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/20800] BFD Linker failing (unresolvable R_X86_64_PLTOFF64) with -mcmodel=large and --start-group
https://sourceware.org/bugzilla/show_bug.cgi?id=20800 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-11-10 CC||hjl.tools at gmail dot com Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- I can't reproduce this on Fedora 24. -- 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/20800] BFD Linker failing (unresolvable R_X86_64_PLTOFF64) with -mcmodel=large and --start-group
https://sourceware.org/bugzilla/show_bug.cgi?id=20800 --- Comment #2 from Keno Fischer --- This is on stock Ubuntu 16.10. Try adding `-fPIE` to the compile invocation maybe? I know Debian recently switched that on 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 gas/20803] New: Sparc R_SPARC_32 reloc with miss-align offset.
https://sourceware.org/bugzilla/show_bug.cgi?id=20803 Bug ID: 20803 Summary: Sparc R_SPARC_32 reloc with miss-align offset. Product: binutils Version: 2.27 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: chrisj at rtems dot org Target Milestone: --- Created attachment 9621 --> https://sourceware.org/bugzilla/attachment.cgi?id=9621&action=edit Sparc ASM showing the miss-aligned R_SPARC_32 reloc offset. I am looking into: https://devel.rtems.org/ticket/2802 where a R_SPARC_32 reloc record with a miss-aligned offset results in a crash. We do not expect a R_SPARC_32 to be miss-aligned. The source is: https://git.rtems.org/rtems/tree/testsuites/libtests/dl05/dl-o5.cpp It seems like emit_expr_fix is being called and it calls TC_CONS_FIX_NEW() without the sparc_no_align_cons being true so R_SPARC_32 reloc type is selected in cons_fix_new_sparc. I do not know if this is an issue in selecting the reloc type, ie sparc_no_align_cons should be true, or the offset should never be miss-aligned. I attach a .s source file that shows the issue. It has been edited removing the .debug output from gcc. -- 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
