[Bug binutils/26132] New: ar creates invalid libraries for some targets with plugins enabled
https://sourceware.org/bugzilla/show_bug.cgi?id=26132 Bug ID: 26132 Summary: ar creates invalid libraries for some targets with plugins enabled Product: binutils Version: 2.35 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: amodra at gmail dot com Target Milestone: --- Targets such as rs6000-aix and alpha-vms that have unusual archive formats can't enable plugin support, because doing so makes ar create the wrong type of archive. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gold/26039] gold doesn't add PIE flag
https://sourceware.org/bugzilla/show_bug.cgi?id=26039 --- Comment #2 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=9a17a136439c200b13a69d453f38824b7edc522c commit 9a17a136439c200b13a69d453f38824b7edc522c Author: Fangrui Song Date: Thu Jun 18 10:46:18 2020 +0100 [PATCH] gold: Set DF_1_PIE for -pie PR gold/26039 * layout.cc (Layout::finish_dynamic_section): Set DF_1_PIE. elfcpp/ * elfcpp.h (enum DF_1): New enum member DF_1_PIE. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25802] Several 64-bit SPARC tests FAIL: relocation truncated to fit
https://sourceware.org/bugzilla/show_bug.cgi?id=25802 Nick Clifton changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #6 from Nick Clifton --- Hi Rainer, Sorry for the long time in replying. Right - there definitely is an overflow occurring. The BFD linker is placing the .text section at 0x1, and so any symbols in that section cannot be referenced by a 32-bit absolute relocation. The reason for this placement, is this piece of code in ld/emulparams/elf64_sparc.sh: case "$target" in sparc*-solaris*) TEXT_START_ADDR=0x1 ;; *) TEXT_START_ADDR=0x10 ;; esac I can only assume that this is deliberate and that changing it would be bad. This does beg the question however of how can valid addresses in the debug or .eh_frame sections be generated if the addresses are > 32-bits ? It looks to me that what ought to happen is for the assembler to generate 64-bit debug information (and call frame info) for the Sparc target on Solaris 2, instead of 32-bit information, which is what it does at the moment. But I do not know if this would then break Solaris native tools that examine this debug information... So the simplest alternative would be to mark the affected tests as XFAIL, with a comment explaining why. A slightly better solution would be to add a "-Ttext=0x1" linker command line option to the tests, although I think that this is hard to do in a target specific way. Thoughts ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/12532] arm: gas may assemble b to locally-defined, preemptible global symbol as "b.n"
https://sourceware.org/bugzilla/show_bug.cgi?id=12532 Jason A. Donenfeld changed: What|Removed |Added CC||jason at zx2c4 dot com --- Comment #9 from Jason A. Donenfeld --- This problem still exists on binutils 2.33 when -fvisibility=hidden is passed to cflags. I imagine this is so due to some conflicting code where the forced B.W is only generated for static functions, since non-static ones will be relocated differently, but then because of -fvisibility=hidden, they get treated like statics, only B is used instead of the forced B.W, causing this issue to crop up again. OpenWRT experienced this when including WireGuard on a new board. I fixed it like this: https://git.zx2c4.com/wireguard-linux-compat/commit/?id=178cdfffb99f2fd6fb4a5bfd2f9319461d93f53b -- You are receiving this mail because: You are on the CC list for the bug.
