[Bug ld/21476] ld generates a RUNPATH instead of a RPATH, breaking tests generated by libtool
https://sourceware.org/bugzilla/show_bug.cgi?id=21476 --- Comment #1 from Vincent Lefèvre --- (In reply to Vincent Lefèvre from comment #0) > Under Debian/unstable (with binutils 2.28), ld now generates a RUNPATH > instead of a RPATH, breaking test programs generated by libtool. Note that this occurs when using libtool's -no-install option, which is recommended for the test programs, e.g. with: AM_LDFLAGS = -no-install in the Makefile.am file of the corresponding directory. This is what MPFR is using, at least for MPFR 3.1.x with x ≤ 5 (currently the latest version). -- 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/21519] [Regression] objdump -r no longer works on archive
https://sourceware.org/bugzilla/show_bug.cgi?id=21519 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8e2f54bcee7e3e8315d4a39a302eaf8e4389e07d commit 8e2f54bcee7e3e8315d4a39a302eaf8e4389e07d Author: H.J. Lu Date: Tue May 30 06:34:05 2017 -0700 Add bfd_get_file_size to get archive element size We can't use stat() to get archive element size. Add bfd_get_file_size to get size for both normal files and archive elements. bfd/ PR binutils/21519 * bfdio.c (bfd_get_file_size): New function. * bfd-in2.h: Regenerated. binutils/ PR binutils/21519 * objdump.c (dump_relocs_in_section): Replace get_file_size with bfd_get_file_size to get archive element size. * testsuite/binutils-all/objdump.exp (test_objdump_f): New proc. (test_objdump_h): Likewise. (test_objdump_t): Likewise. (test_objdump_r): Likewise. (test_objdump_s): Likewise. Add objdump tests on archive. -- 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/21519] [Regression] objdump -r no longer works on archive
https://sourceware.org/bugzilla/show_bug.cgi?id=21519 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from H.J. Lu --- Fixed. -- 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/21523] Relocation for R_ARM_THM_ALU_PREL_11_0 is not calculated correctly
https://sourceware.org/bugzilla/show_bug.cgi?id=21523 --- Comment #6 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=8c65b54f18c03ffb844e1cbaa3b46b43444ff9e7 commit 8c65b54f18c03ffb844e1cbaa3b46b43444ff9e7 Author: Casey Smith Date: Tue May 30 15:07:56 2017 +0100 Fix calculation of R_ARM_RHM_ALU_PREL_11_0 relocation when used with a SUB instruction. PR ld/21523 * elf32-arm.c (elf32_arm_final_link_relocate): Install an absolute value when processing the R_ARM_THM_ALU_PREL_11_0 reloc. -- 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/21523] Relocation for R_ARM_THM_ALU_PREL_11_0 is not calculated correctly
https://sourceware.org/bugzilla/show_bug.cgi?id=21523 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #7 from Nick Clifton --- Hi Casey, Thanks very much for reporting this bug and providing a patch. I am not sure why clang was complaining about the abs() invocation but it obviously is needed, so I am happy to put it back. Patch applied. 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/21532] New: AArch64: Symbol address inconsistency across compilation units
https://sourceware.org/bugzilla/show_bug.cgi?id=21532 Bug ID: 21532 Summary: AArch64: Symbol address inconsistency across compilation units Product: binutils Version: 2.29 (HEAD) Status: NEW Severity: critical Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: nickc at redhat dot com Target Milestone: --- Created attachment 10074 --> https://sourceware.org/bugzilla/attachment.cgi?id=10074&action=edit Demonstration of the bug The unit test fails on AArch64 and passes on x86-64, s390x and ppc64. A static const struct (APFloat::IEEEsingle) is defined in the shared library (libLLVM.so) and accessed both from within the library as well as the executable that links against the shared library. On AArch64, taking the address of IEEEsingle yields different results for code in the executable and code in the shared library. It looks like the linker creates a copy of IEEEsingle in the executable but then the GOT entry for IEEEsingle is not updated in libLLVM.so, causing any accesses to IEEEsingle in libLLVM.so to refer to the original definition (which in itself is not a big problem as all the data is constant). However, this breaks the LLVM APFloat class because it uses the addresses of the various static const structs (IEEEsingle, IEEEdouble, IEEEquad, x87DoubleExtended, etc. which define the properties of the different floating point types) to dispatch on the floating point type in the member functions of APFloat. Thus it is crucial that any of those constants always have the same address no matter where they are referenced from. APFloat is an arbitrary precision floating point implementation that is used in various places across the whole compiler, e.g. there are various codepaths involving APFloat that will lead to crashes on AArch64. Running the attached test case should yield the following output on AArch64: $ ./build.sh Address of IEEEsingle (APFloatTest.cpp): 0x420208 Address of IEEEsingle (APFloat.cpp): 0x3ff78cf0a58 And the following output on x86-64: $ ./build.sh Address of IEEEsingle (APFloatTest.cpp): 0x7fbedc3cc9a0 Address of IEEEsingle (APFloat.cpp): 0x7fbedc3cc9a0 As you can see the addresses are not consistent on AArch64. -- 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/21532] AArch64: Symbol address inconsistency across compilation units
https://sourceware.org/bugzilla/show_bug.cgi?id=21532 Florian Weimer changed: What|Removed |Added CC||fweimer 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
