[Bug ld/21458] ld generates none ARM elf ABI compliant code that causes a hard fault.
https://sourceware.org/bugzilla/show_bug.cgi?id=21458 --- 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=e645cf40b111daef4518a58547de577eb9379ccb commit e645cf40b111daef4518a58547de577eb9379ccb Author: Andrew Goedhart Date: Tue May 9 12:14:48 2017 +0100 Fix resolution of R_ARM_THM_ALU_PREL_11_0 relocation against Thumb symbols. PR ld/21458 * elf32-arm.c (elf32_arm_final_link_relocate): Set the bottom bit of the value when resolving a R_ARM_THM_ALU_PREL_11_0 relocation and the destination is a Thumb symbol. -- 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/21458] ld generates none ARM elf ABI compliant code that causes a hard fault.
https://sourceware.org/bugzilla/show_bug.cgi?id=21458 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #5 from Nick Clifton --- Hi Andrew, I am very sorry for dropping the ball on this PR and not reviewing it until now. I have gone ahead and checked in your patch. One thing extra that I would like to do is to add a new testcase to the linker testsuite, to make sure that this problem stays fixed. Do you have some (small) assembler sources that can be used to trigger this bug ? 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/21471] ld rejects pe-bigobj-x86-64 target but shouldn't
https://sourceware.org/bugzilla/show_bug.cgi?id=21471 --- 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=a6da46304894741d50a6f4ca2263b5cc158740e4 commit a6da46304894741d50a6f4ca2263b5cc158740e4 Author: Awson Date: Tue May 9 14:42:43 2017 +0100 Support pe-bigobj-x86-64 as an output format in 64-bit PE based linkers. PR ld/21471 * pe-dll.c (pe_detail_list): Add entry for pe-bigobj-x86-64. -- 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/21471] ld rejects pe-bigobj-x86-64 target but shouldn't
https://sourceware.org/bugzilla/show_bug.cgi?id=21471 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Patch approved and applied. Thanks very much for reporting & fixing this problem! 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/21476] New: ld generates a RUNPATH instead of a RPATH, breaking tests generated by libtool
https://sourceware.org/bugzilla/show_bug.cgi?id=21476 Bug ID: 21476 Summary: ld generates a RUNPATH instead of a RPATH, breaking tests generated by libtool Product: binutils Version: 2.28 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: vincent-srcware at vinc17 dot net Target Milestone: --- Under Debian/unstable (with binutils 2.28), ld now generates a RUNPATH instead of a RPATH, breaking test programs generated by libtool. To reproduce: 1. Install some MPFR version somewhere (in my case 3.1.5-p2, i.e. with the current patches). 2. Define LD_LIBRARY_PATH to use it normally. 3. Go to the source directory of a different MPFR version (but ABI compatible), e.g. the 3.1 branch (a.k.a. 3.1.6-dev) or just 3.1.5. 4. ./configure 5. make 6. make check Almost all the tests fail, the reason being that the tested MPFR library is not the one that has just been built with "make", but the one found via LD_LIBRARY_PATH! This is incorrect, because the goal of "make check" is to test the library from the build directory. Debian jessie (which has binutils 2.25) does not have this problem. On such a machine, "objdump -p tversion" gives something like: [...] Dynamic Section: NEEDED libm.so.6 NEEDED libmpfr.so.4 NEEDED libgmp.so.10 NEEDED libc.so.6 NEEDED ld-linux-x86-64.so.2 RPATH /home/vlefevre/software/mpfr-3.1/src/.libs:/home/vlefevre/debian8/gmp/k10/lib INIT 0x00401578 [...] as expected. Note that here: * /home/vlefevre/software/mpfr-3.1 corresponds to the source directory mentioned in step 3. * /home/vlefevre/debian8/gmp/k10/lib is where I have installed MPFR 3.1.5-p2. On my Debian/unstable machine (where almost all the tests fail), "objdump -p tversion" gives: [...] Dynamic Section: NEEDED libm.so.6 NEEDED libmpfr.so.4 NEEDED libgmp.so.10 NEEDED libc.so.6 NEEDED ld-linux-x86-64.so.2 RUNPATH /home/vlefevre/software/mpfr-3.1/src/.libs INIT 0x1648 [...] Since RUNPATH is used instead of RPATH, LD_LIBRARY_PATH now has the precedence. Hence the breakage. FYI, here what libtool does on the Debian jessie machine: libtool: link: gcc -std=gnu99 -Wall -Wmissing-prototypes -Wpointer-arith -O2 -pedantic -fomit-frame-pointer -m64 -mtune=amdfam10 -march=amdfam10 -o tversion tversion.o -L../src/.libs ./.libs/libfrtests.a -lm ../src/.libs/libmpfr.so /home/vlefevre/debian8/gmp/k10/lib/libgmp.so -Wl,-rpath -Wl,/home/vlefevre/software/mpfr-3.1/src/.libs -Wl,-rpath -Wl,/home/vlefevre/debian8/gmp/k10/lib -Wl,-rpath -Wl,/home/vlefevre/debian8/gmp/k10/lib and on my Debian/unstable machine: libtool: link: gcc -Wall -Wmissing-prototypes -Wpointer-arith -g -O2 -o tversion tversion.o -L../src/.libs ./.libs/libfrtests.a -lm ../src/.libs/libmpfr.so -lgmp -Wl,-rpath -Wl,/home/vlefevre/software/mpfr-3.1/src/.libs This is a bit different, but what really matters here is the: -Wl,-rpath -Wl,... in both cases. On the Debian jessie machine: lrwxrwxrwx 1 6 2015-02-25 09:00:51 /usr/bin/ld -> ld.bfd On my Debian/unstable machine: lrwxrwxrwx 1 19 2017-04-18 03:38:02 /usr/bin/ld -> x86_64-linux-gnu-ld lrwxrwxrwx 1 6 2017-04-18 03:38:02 /usr/bin/x86_64-linux-gnu-ld -> ld.bfd I initially reported this bug in the Debian BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859732 There doesn't seem to be any Debian patch that changes this 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
[Bug ld/21458] ld generates none ARM elf ABI compliant code that causes a hard fault.
https://sourceware.org/bugzilla/show_bug.cgi?id=21458
--- Comment #6 from Andrew Goedhart ---
Hi Nick
Thanks for the merge.
I can't generate a test case because using gas, the ADR instruction
insists that the label be in the same section and file. So no
relocation is generated because the only code the assembler generates
is PC relative and therefore does not require relocation. I am
guessing this is why the problem was hidden for so long.
Unfortunately we may potentially have another problem. When trying to
generate a test case I came across the following.
The test case below generates incorrect code for the ADR instruction
in conjunction with a thumb_func target..
.syntax unified
.thumb
.text
.align 2
.global __testFnPtr
.type __testFnPtr, %function
.thumb_func
__testFnPtr:
bx lr
.global __testArmThmAluPre
.type __testArmThmAluPre, %function
.thumb_func
__testArmThmAluPre:
Push {LR}
ADR R0,__testFnPtr
BLX R0
Pop {PC}
-
this results in the following disassembly
__testFnPtr:
98e8: 0x7047 bx lr
__testArmThmAluPre:
98ea: 0x00b5 push{lr}
98ec: 0xaff20800 subwr0, pc, #8
98f0: 0x8047 blx r0
98f2: 0x00bd pop {pc}
The problem is that the thumb bit is not set ( subwr0, pc, #8
results in an even address) and that this code causes a hard fault.
Now I don't know my assembly as well as I should so there might be
wrong/missing directives in the above file. Comment welcome
regards
Andrew Goedhart
On Tue, May 9, 2017 at 1:21 PM, nickc at redhat dot com
wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=21458
>
> Nick Clifton changed:
>
>What|Removed |Added
>
> Status|UNCONFIRMED |RESOLVED
> CC||nickc at redhat dot com
> Resolution|--- |FIXED
>
> --- Comment #5 from Nick Clifton ---
> Hi Andrew,
>
> I am very sorry for dropping the ball on this PR and not reviewing it until
> now.
>
> I have gone ahead and checked in your patch. One thing extra that I would
> like to do is to add a new testcase to the linker testsuite, to make sure that
> this problem stays fixed. Do you have some (small) assembler sources that can
> be used to trigger this bug ?
>
> Cheers
> Nick
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You reported the bug.
--
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/21459] Wrong location for .debug_gdb_scripts on Windows
https://sourceware.org/bugzilla/show_bug.cgi?id=21459 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Created attachment 10043 --> https://sourceware.org/bugzilla/attachment.cgi?id=10043&action=edit Proposed patch Hi Egon, Please could you try out this patch ? I think that it should work for debugging sections (ie ones starting with .debug) but it may not solve the general problem of an arbitrary named, non-empty, non-loaded section being placed at VMA 0. 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 gold/21444] internal error in relocate_tls, at ../../gold/sparc.cc:3789
https://sourceware.org/bugzilla/show_bug.cgi?id=21444 John Paul Adrian Glaubitz changed: What|Removed |Added CC||nickc at redhat 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 gold/21444] internal error in relocate_tls, at ../../gold/sparc.cc:3789
https://sourceware.org/bugzilla/show_bug.cgi?id=21444 --- Comment #2 from John Paul Adrian Glaubitz --- I can confirm that James' patch fixes the issue and systemd builds fine with the binutils patch applied. -- 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
