[Bug ld/3843] New: Extra libpath (32-bit) on GNU/kFreeBSD
The patch below adds the elf_i386_fbsd as an extra libpath on GNU/kFreeBSD
amd64. This is needed to support 32-bit binaries on this system.
Could you please apply it? Thanks.
Index: ld/configure.tgt
===
RCS file: /cvs/src/src/ld/configure.tgt,v
retrieving revision 1.200
diff -u -d -p -r1.200 configure.tgt
--- ld/configure.tgt24 Dec 2006 02:48:59 - 1.200
+++ ld/configure.tgt8 Jan 2007 01:02:11 -
@@ -219,6 +219,9 @@ i[3-7]86-*-freebsd* | i[3-7]86-*-kfreebs
x86_64-*-freebsd* | x86_64-*-kfreebsd*-gnu)
targ_emul=elf_x86_64_fbsd
targ_extra_emuls="elf_i386_fbsd elf_x86_64 elf_i386"
+ targ_extra_libpath="elf_i386_fbsd"
+ tdir_elf_i386_fbsd=`echo ${targ_alias} \
+ | sed -e 's/x86_64/i386/'`
tdir_elf_i386=`echo ${targ_alias} \
| sed -e 's/x86_64/i386/'` ;;
i[3-7]86-*-sysv*) targ_emul=i386coff ;;
--
Summary: Extra libpath (32-bit) on GNU/kFreeBSD
Product: binutils
Version: 2.18 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: aurelien at aurel32 dot net
CC: bug-binutils at gnu dot org
GCC build triplet: x86_64-unknown-kfreebsd6.1-gnu
GCC host triplet: x86_64-unknown-kfreebsd6.1-gnu
GCC target triplet: x86_64-unknown-kfreebsd6.1-gnu
http://sourceware.org/bugzilla/show_bug.cgi?id=3843
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/3826] elf_object_p can't tell freebsd object file from standard ELF object file
--- Additional Comments From aurelien at aurel32 dot net 2007-03-05 17:07 --- I have just tried again with the current CVS version. It seems the patch posted on http://sourceware.org/ml/binutils/2007-01/msg00045.html has not been applied, thus objdump and nm are not working correctly: /usr/bin/nm: Matching formats: elf32-i386-freebsd elf32-i386 /usr/bin/nm: libgcc/32/_lshrdi3_s.o: File format is ambiguous or objdump: /lib32/libpthread.so.0: File format is ambiguous objdump: Matching formats: elf32-i386-freebsd elf32-i386 It is actually only necessary to remove elf32-i386. Please find a patch below to fix that. I have been able to build a full gcc 4.1 and a full glibc with it. Would it be possible to apply it, at least until elf_object_p is fixed? --- binutils-2.17.20070210cvs.orig/bfd/config.bfd +++ binutils-2.17.20070210cvs/bfd/config.bfd @@ -577,7 +577,7 @@ ;; x86_64-*-freebsd* | x86_64-*-kfreebsd*-gnu) targ_defvec=bfd_elf64_x86_64_freebsd_vec -targ_selvecs="bfd_elf32_i386_freebsd_vec i386coff_vec bfd_efi_app_ia32_vec bfd_elf32_i386_vec bfd_elf64_x86_64_vec" +targ_selvecs="bfd_elf32_i386_freebsd_vec i386coff_vec bfd_efi_app_ia32_vec bfd_elf64_x86_64_vec" want64=true ;; x86_64-*-netbsd* | x86_64-*-openbsd*) -- http://sourceware.org/bugzilla/show_bug.cgi?id=3826 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4453] New: ar doesn't recognize ELF64 on mips
ar (and ranlib) do not correctly identify ELF64 files in an archive. It complains that the format is ambiguous. See the testcase below: [tesla:~]$ touch foo.c [tesla:~]$ gcc -mabi=64 -o foo.o -c foo.c [tesla:~]$ ar cq libfoo.a foo.o [tesla:~]$ ar t libfoo.a ar: libfoo.a: File format is ambiguous ar: Matching formats: ecoff-littlemips ecoff-bigmips elf64-tradlittlemips [tesla:~]$ -- Summary: ar doesn't recognize ELF64 on mips Product: binutils Version: 2.18 (HEAD) Status: NEW Severity: normal Priority: P2 Component: binutils AssignedTo: unassigned at sources dot redhat dot com ReportedBy: aurelien at aurel32 dot net CC: bug-binutils at gnu dot org GCC build triplet: mipsel-unknown-linux-gnu GCC host triplet: mipsel-unknown-linux-gnu GCC target triplet: mipsel-unknown-linux-gnu http://sourceware.org/bugzilla/show_bug.cgi?id=4453 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/4497] New: [regression] ld fails to link C++ code
Since the patch from bug PR4454 has been applied to the CVS, ld segfaults when
linking C++/Java code.
Without patch from PR4454:
$ cat test.cpp
#include
int main()
{
std::cout << "Hello World!\n" << std::endl;
return 0;
}
$ g++ -o test test.cpp
$ ./test
Hello World!
$
With patch from PR4454:
$ g++ -o test test.cpp
collect2: ld terminated with signal 11 [Segmentation fault]
$
--
Summary: [regression] ld fails to link C++ code
Product: binutils
Version: 2.17
Status: NEW
Severity: critical
Priority: P2
Component: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: aurelien at aurel32 dot net
CC: bug-binutils at gnu dot org
GCC build triplet: mipsel-unknown-linux-gnu
GCC host triplet: mipsel-unknown-linux-gnu
GCC target triplet: mipsel-unknown-linux-gnu
http://sourceware.org/bugzilla/show_bug.cgi?id=4497
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/4497] [regression] ld fails to link C++ code on mips/mipsel
--- Additional Comments From aurelien at aurel32 dot net 2007-05-12 11:38 --- I forget to explicitely say it happens on mips/mipsel. -- What|Removed |Added Summary|[regression] ld fails to|[regression] ld fails to |link C++ code |link C++ code on mips/mipsel http://sourceware.org/bugzilla/show_bug.cgi?id=4497 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/4497] [regression] ld fails to link C++ code on mips/mipsel
-- What|Removed |Added Version|2.17|2.18 (HEAD) http://sourceware.org/bugzilla/show_bug.cgi?id=4497 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/4497] [regression] ld fails to link C++ code on mips/mipsel
--- Additional Comments From aurelien at aurel32 dot net 2007-05-13 00:38 --- (In reply to comment #2) > There's a good chance http://sourceware.org/ml/binutils/2007-05/msg00154.html > will fix this for you. Yes, that works, thanks a lot. -- http://sourceware.org/bugzilla/show_bug.cgi?id=4497 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4453] ar doesn't recognize ELF64 on mips
--- Additional Comments From aurelien at aurel32 dot net 2008-01-17 11:35 --- The binutils on which the problem exists is already built with "--enable-targets=mips64el-linux-gnu". It is confirmed by the error message: ar: Matching formats: ecoff-littlemips ecoff-bigmips elf64-tradlittlemips What should be the correct --enable-targets for 64-bit mipsel? -- http://sourceware.org/bugzilla/show_bug.cgi?id=4453 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4453] ar doesn't recognize ELF64 on mips
--- Additional Comments From aurelien at aurel32 dot net 2008-01-18 20:24 --- I am not able to reproduce the problem anymore with the latest CVS. I guess the problem has been fixed recently, but I don't know exactly when. Thanks for the fix. -- http://sourceware.org/bugzilla/show_bug.cgi?id=4453 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/4453] ar doesn't recognize ELF64 on mips
--- Additional Comments From aurelien at aurel32 dot net 2008-01-23 23:48 --- Thanks a lot for the fix. I have just tested and it works fine for me. -- http://sourceware.org/bugzilla/show_bug.cgi?id=4453 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/20649] [MIPS] Can't find matching LO16 reloc
https://sourceware.org/bugzilla/show_bug.cgi?id=20649 Aurelien Jarno changed: What|Removed |Added CC||aurelien at aurel32 dot net -- 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/20649] [MIPS] Can't find matching LO16 reloc
https://sourceware.org/bugzilla/show_bug.cgi?id=20649 --- Comment #6 from Aurelien Jarno --- (In reply to Maciej W. Rozycki from comment #5) > Sure, the GNU GPL applies. Due to other commitments it'll take me a > few days yet to get the test cases made, but I don't plan to change the > code update itself any further, so any future merge from upstream > Debian people will make should result in an easy to resolve "can be > reverse-applied" result. > > NB I'm still waiting to have my Bugzilla permissions restored (there's > been some confusion around it), which is why I wasn't able to update > the status of this bug. Ping. Do you think this can be merged now? Thanks. -- 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/20649] [MIPS] Can't find matching LO16 reloc
https://sourceware.org/bugzilla/show_bug.cgi?id=20649 --- Comment #8 from Aurelien Jarno --- (In reply to Maciej W. Rozycki from comment #7) > I yet need to integrate the test case with the test suite, > but please be assured this fix will make it to 2.28. Thanks! -- 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/21054] [MIPS] Forced local symbol rearranging messes up GOT
https://sourceware.org/bugzilla/show_bug.cgi?id=21054 Aurelien Jarno changed: What|Removed |Added CC||aurelien at aurel32 dot net -- 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/29940] New: fails to correctly assemble the JAL instruction on riscv64
https://sourceware.org/bugzilla/show_bug.cgi?id=29940 Bug ID: 29940 Summary: fails to correctly assemble the JAL instruction on riscv64 Product: binutils Version: unspecified URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026 979 Status: NEW Severity: critical Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: aurelien at aurel32 dot net CC: jbeulich at suse dot com Target Milestone: --- Host: riscv64-unknown-linux-gnu Target: riscv64-unknown-linux-gnu Build: riscv64-unknown-linux-gnu inutils on riscv64 fails to correctly assemble the JAL instruction when used without implicit register, that is in the format JAL reg, imm. This can be reproduced with this simple test program: .text 1: jal zero, 1b With recent binutils versions, "zero" is not interpreted as a register, but instead as the immediate value, and therefore a relocation is emitted. This happens also when using other register names such as "a1" or "x0". This causes the linux packages to fails to build due to unresolved symbols in kernel modules: ERROR: modpost: "zero" [arch/riscv/kvm/kvm.ko] undefined! ERROR: modpost: "zero" [mm/z3fold.ko] undefined! ERROR: modpost: "zero" [fs/mbcache.ko] undefined! ERROR: modpost: "zero" [fs/fscache/fscache.ko] undefined! ERROR: modpost: "zero" [fs/jbd2/jbd2.ko] undefined! ERROR: modpost: "zero" [fs/nfs/nfs.ko] undefined! ERROR: modpost: "zero" [fs/nfs/nfsv4.ko] undefined! ERROR: modpost: "zero" [fs/nfsd/nfsd.ko] undefined! ERROR: modpost: "zero" [fs/ufs/ufs.ko] undefined! ERROR: modpost: "zero" [fs/xfs/xfs.ko] undefined! The issue has been introduced by this commit: commit 839189bc932ea02c9647a3ad829dda72f8a9562c Author: Jan Beulich Date: Fri Sep 30 10:19:00 2022 +0200 RISC-V: re-arrange opcode table for consistent alias handling For disassembly to pick up aliases in favor of underlying insns (helping readability in the common case), the aliases need to come ahead of the "base" insns. Slightly more code movement is needed because of insns with the same name needing to stay next to each other. Note that the "rorw" alias entry also has the missing INSN_ALIAS added here. Clone a few testcases to exercise -Mno-aliases some more, better covering the differences between the default and that disassembly mode. Reverting the first hunk of the opcodes/riscv-opc.c patch fixes the issue. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29940] fails to correctly assemble the JAL instruction on riscv64
https://sourceware.org/bugzilla/show_bug.cgi?id=29940 --- Comment #2 from Aurelien Jarno --- Try with: $ readelf -s a.out | grep GLOBAL 7: 0 NOTYPE GLOBAL DEFAULT UND zero -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28441] [RISCV] ld linker relaxation is really slow
https://sourceware.org/bugzilla/show_bug.cgi?id=28441 Aurelien Jarno changed: What|Removed |Added CC||aurelien at aurel32 dot net -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31133] New: [riscv64] -z now breaks glibc testsuite
https://sourceware.org/bugzilla/show_bug.cgi?id=31133 Bug ID: 31133 Summary: [riscv64] -z now breaks glibc testsuite Product: binutils Version: 2.41 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: aurelien at aurel32 dot net Target Milestone: --- Building glibc 2.38 with --enable-bind-now on riscv64 with the current binutils binutils-2_41-branch branch (actually through the sid debian package in version 2.41.50.20231206-1) causes the elf/tst-audit1 elf/tst-audit2 elf/tst-audit8 tests to fail with a segfault. Not using --enable-bind-now, that is not passing -z now to ld, workaround the issue. This is a regression from version 2.41, for which the tests pass with both with and without --enable-bind-now. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31133] [riscv64] -z now breaks glibc testsuite
https://sourceware.org/bugzilla/show_bug.cgi?id=31133 Aurelien Jarno changed: What|Removed |Added Host||riscv64-unknown-linux-gnu Build||riscv64-unknown-linux-gnu Target||riscv64-unknown-linux-gnu -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31133] [riscv64] -z now breaks glibc testsuite
https://sourceware.org/bugzilla/show_bug.cgi?id=31133 --- Comment #1 from Aurelien Jarno --- Created attachment 15251 --> https://sourceware.org/bugzilla/attachment.cgi?id=15251&action=edit Reproducer I have attached a (big) reproduced for this bug. This is basically the files from the glibc build tree and the associated tests. Just use run.sh to link libc.so with and without -z now and see the difference in the testsuite result -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31133] [riscv64] -z now breaks glibc testsuite
https://sourceware.org/bugzilla/show_bug.cgi?id=31133 Aurelien Jarno changed: What|Removed |Added CC||aurelien at aurel32 dot net, ||sch...@linux-m68k.org --- Comment #2 from Aurelien Jarno --- A bisect pointed me to the following commit: 7345d05aafde53a48d5a587a6d9c1778db78e0f3 is the first bad commit commit 7345d05aafde53a48d5a587a6d9c1778db78e0f3 Author: Andreas Schwab Date: Thu Sep 21 16:49:41 2023 +0200 RISC-V: Protect .got with relro Move .got before .data so that it can be protected with -zrelro. Also separate .got.plt from .got if -znow is not in effect; the first two words of .got.plt are placed within the relro region. ld: PR ld/30877 * emulparams/elf32lriscv-defs.sh (DATA_GOT, SEPARATE_GOTPLT): Define. * emulparams/elf64lriscv-defs.sh (SEPARATE_GOTPLT): Define. * testsuite/ld-elf/binutils.exp (binutils_test): Remove riscv*-*-* from relro_got expression. ld/emulparams/elf32lriscv-defs.sh | 4 ld/emulparams/elf64lriscv-defs.sh | 1 + ld/testsuite/ld-elf/binutils.exp | 1 - 3 files changed, 5 insertions(+), 1 deletion(-) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31133] [riscv64] -z now breaks glibc testsuite
https://sourceware.org/bugzilla/show_bug.cgi?id=31133 Aurelien Jarno changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #4 from Aurelien Jarno --- (In reply to Andreas Schwab from comment #3) > Which means it is a bug in glibc. Ok, thanks, I have opened bug #31151. Closing the bug here. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25501] New: STT_GNU_IFUNC causes assertion on 64-bit RISC-V
https://sourceware.org/bugzilla/show_bug.cgi?id=25501 Bug ID: 25501 Summary: STT_GNU_IFUNC causes assertion on 64-bit RISC-V Product: binutils Version: 2.34 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: aurelien at aurel32 dot net Target Milestone: --- Created attachment 12250 --> https://sourceware.org/bugzilla/attachment.cgi?id=12250&action=edit Script to reproduce the issue Starting with GNU libc 2.30, the testsuite includes some IFUNC related tests even if only the assembler and the linker supports that feature (as opposed to compiler, assembler and linker before). Some of the tests can not be linked as they trigger an assertion in LD: /usr/bin/ld: BFD (GNU Binutils for Debian) 2.34 assertion fail ../../bfd/elfnn-riscv.c:2507 /usr/bin/ld: BFD (GNU Binutils for Debian) 2.34 assertion fail ../../bfd/elfnn-riscv.c:2508 /usr/bin/ld: BFD (GNU Binutils for Debian) 2.34 assertion fail ../../bfd/elfnn-riscv.c:2507 /usr/bin/ld: BFD (GNU Binutils for Debian) 2.34 assertion fail ../../bfd/elfnn-riscv.c:2507 collect2: error: ld returned 1 exit status I have added a reproducer script with sources extracted from the GNU libc as an attachment. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25501] STT_GNU_IFUNC causes assertion on 64-bit RISC-V
https://sourceware.org/bugzilla/show_bug.cgi?id=25501 --- Comment #1 from Aurelien Jarno --- Note that this is on Debian where GCC default to PIE. You might have to pass -fPIE to be able to reproduce the issue (it is not reproducible with -fno-PIE). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25501] STT_GNU_IFUNC causes assertion on 64-bit RISC-V
https://sourceware.org/bugzilla/show_bug.cgi?id=25501 --- Comment #3 from Aurelien Jarno --- Thanks for the fast answer. I understand that the support is missing, and that it might take time to add it. The problem is not directly the missing support, but the fact that basic support is there, which is enough for the GNU libc configure script to detect that IFUNC support is available: https://sourceware.org/git/?p=glibc.git;a=blob;f=configure.ac;h=49b900c1ed68fa4dd1dadca809ceb6e8b237a89c;hb=HEAD#l629 Would it actually make sense to make sure such a simple test fails to build until there is a full support, so that the feature gets entirely disabled on the GNU libc side? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25501] STT_GNU_IFUNC causes assertion on 64-bit RISC-V
https://sourceware.org/bugzilla/show_bug.cgi?id=25501 --- Comment #5 from Aurelien Jarno --- It does succeed here (glibc 2.30, binutils 2.34, gcc 9.2.1): configure:4009: checking for assembler and linker STT_GNU_IFUNC support Relocation section '.rela.dyn' at offset 0x268 contains 1 entry: Offset Info Type Sym. ValueSym. Name + Addend 2000 0003 R_RISCV_RELATIVE 280 configure:4040: result: yes -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25501] STT_GNU_IFUNC causes assertion on 64-bit RISC-V
https://sourceware.org/bugzilla/show_bug.cgi?id=25501 --- Comment #7 from Aurelien Jarno --- It creates a relocation because my GCC defaults to -pie. It is not present when I compile conftest.S with -no-pie. I observe the same behaviour with MIPS, which doesn't support IFUNC. It looks like the GNU libc configure test is therefore broken. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25501] STT_GNU_IFUNC causes assertion on 64-bit RISC-V
https://sourceware.org/bugzilla/show_bug.cgi?id=25501 --- Comment #8 from Aurelien Jarno --- I have opened a bug on the GNU libc side: https://sourceware.org/bugzilla/show_bug.cgi?id=25506 And posted the corresponding patch: https://sourceware.org/ml/libc-alpha/2020-02/msg00084.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/10144] New: mips/ld: non-dynamic relocations refer to dynamic symbol
ld from binutils version 2.19.1, but also from the trunk version, is failing to link some objects on mips and mipsel, o32 ABI, with the following error: | ld: non-dynamic relocations refer to dynamic symbol pthread_cancel@@GLIBC_2.0 | ld: failed to set dynamic section sizes: Bad value This happens for example during the bootstrap of gcc 4.4 or in software such as mplayer. I have tracked down this regression between 2008-08-08 and 2008-08-09. That corresponds to the addition of plt support. I have been able to do a simple testcase from sources, so I will attach a tarball containing objects from gcc 4.4 and the command to link them. -- Summary: mips/ld: non-dynamic relocations refer to dynamic symbol Product: binutils Version: 2.20 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassigned at sources dot redhat dot com ReportedBy: aurelien at aurel32 dot net CC: bug-binutils at gnu dot org GCC build triplet: mips-unknown-linux-gnu GCC host triplet: mips-unknown-linux-gnu GCC target triplet: mips-unknown-linux-gnu http://sourceware.org/bugzilla/show_bug.cgi?id=10144 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10144] mips/ld: non-dynamic relocations refer to dynamic symbol
--- Additional Comments From aurelien at aurel32 dot net 2009-05-11 14:02 --- Created an attachment (id=3931) --> (http://sourceware.org/bugzilla/attachment.cgi?id=3931&action=view) testcase -- http://sourceware.org/bugzilla/show_bug.cgi?id=10144 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10858] New: ld generate broken PIE binaries on MIPS
Most PIE binaries generated on MIPS are broken. Here is a small testcase to
demonstrate the problem:
/* compile with cc -pie -fPIE -o fpie fpie.c */
#include
#include
int val0 = 3;
int val1 = 4;
int *vals[2] = {
&val0,
&val1
};
int main(void)
{
printf("val0 is %i\n", *vals[0]);
printf("val1 is %i\n", *vals[1]);
return 0;/* compile with cc -pie -fPIE -o fpie fpie.c */
#include
#include
int val0 = 3;
int val1 = 4;
int *vals[2] = {
&val0,
&val1
};
int main(void)
{
printf("val0 is %i\n", *vals[0]);
printf("val1 is %i\n", *vals[1]);
return 0;
}
Note that for an unknown reason, gcc 4.3 does not generate a pie binary
with -pie (not specific to MIPS), so you may want to try it with gcc 4.1.
Such a code crashes on startup during the relocation phase. This is due to a
wrong ELF header. Compared to a working binutils, val0 and val1 do not appear
in '.dynsym'. As a consequence '.rel.dyn' is filled with bad entries, causing
the crash:
Relocation section '.rel.dyn' at offset 0x594 contains 5 entries:
Offset InfoTypeSym.Value Sym. Name
R_MIPS_NONE
00010ab0 0003 R_MIPS_REL32
00010ab4 0003 R_MIPS_REL32
00010ad0 ff03 R_MIPS_REL32 bad symbol index: 00ff
00010ad4 ff03 R_MIPS_REL32 bad symbol index: 00ff
Manually editing '.rel.dyn' with an hex editor to point the entries to another
symbol cause the crash to disappear. Of course the value is then wrong.
--
Summary: ld generate broken PIE binaries on MIPS
Product: binutils
Version: 2.20
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: unassigned at sources dot redhat dot com
ReportedBy: aurelien at aurel32 dot net
CC: bug-binutils at gnu dot org
GCC build triplet: mipsel-unknown-linux-gnu
GCC host triplet: mipsel-unknown-linux-gnu
GCC target triplet: mipsel-unknown-linux-gnu
http://sourceware.org/bugzilla/show_bug.cgi?id=10858
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10858] ld generate broken PIE binaries on MIPS
--- Additional Comments From aurelien at aurel32 dot net 2009-10-29 08:33 --- Unfortunately, bisecting takes time, especially on my slow machine. What I can tell for now is that the CVS from 2008/07/03 works the CVS from 2008/08/14 does not work. About the gcc 4.3 issue not activating pie with the -pie flag, it only happens if the output filename contains fpie. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10858 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10858] ld generate broken PIE binaries on MIPS
--- Additional Comments From aurelien at aurel32 dot net 2009-11-01 10:44 --- The problem has been introduced by this (huge) changeset: 2008-08-07 Richard Sandiford * elf-bfd.h (elf_backend_data): Add a "rela_plts_and_copies_p" field. * elfxx-target.h (elf_backend_rela_plts_and_copies_p): New macro. (elfNN_bed): Use it. * elf.c (_bfd_elf_get_synthetic_symtab): Use rela_plts_and_copies_p instead of default_use_rela_p to choose between ".rel.plt" and ".rela.plt". * elflink.c (_bfd_elf_create_dynamic_sections): Use rela_plts_and_copies_p instead of default_use_rela_p to choose between ".rel.plt" and ".rela.plt", and between ".rel.bss" and ".rela.bss". 2008-08-07 Richard Sandiford * elf-bfd.h (MIPS_ELF_TDATA): New elf_object_id. * elf32-mips.c (bfd_elf32_mkobject): Define. * elf64-mips.c (bfd_elf64_mkobject): Likewise. * elfn32-mips.c (bfd_elf32_mkobject): Likewise. * elfxx-mips.h (_bfd_mips_elf_mkobject): Declare. * elfxx-mips.c (is_mips_elf): New macro. (_bfd_mips_elf_mkobject): New function. (_bfd_mips_elf_final_link): Use is_mips_elf. (_bfd_mips_elf_merge_private_bfd_data): Likewise. 2008-08-07 Richard Sandiford * elfxx-mips.c (mips_elf_record_relocs): Defer allocation of a global GOT entry when deferring allocation of dynamic relocations. (allocate_dynrelocs): When allocating deferred dynamic relocations, also do the deferred allocation of a GOT entry. 2008-08-07 Richard Sandiford * elfxx-mips.c (mips_got_info): Add a "reloc_only_gotno" field. (mips_elf_got_section): Delete. (mips_elf_sort_hash_table): Use g->reloc_only_gotno to decide how many reloc-only entries there are. (mips_elf_count_got_symbols): Adjust g->reloc_only_gotno as well as g->global_gotno. (mips_elf_make_got_per_bfd): Initialize reloc_only_gotno. (mips_elf_multi_got): Likewise. Use gg->reloc_only_gotno rather than gg->assigned_gotno to store the number of reloc-only GOT entries. (mips_elf_create_got_section): Remove the MAYBE_EXCLUDE parameter. Initialize reloc_only_gotno. (mips_elf_calculate_relocation): Check htab->got_info instead of dynobj when deciding whether to call mips_elf_adjust_gp, (_bfd_mips_elf_create_dynamic_sections): Adjust the call to mips_elf_create_got_section. (mips_elf_record_relocs): Likewise. Remove redundant "dynobj == NULL" code. Do not use mips_elf_create_got_section or mips_elf_record_global_got_symbol for R_MIPS_32, R_MIPS_REL32 and R_MIPS_64; limit global_got_area to GGA_RELOC_ONLY instead. (_bfd_mips_elf_finish_dynamic_symbol): Use htab->sgot instead of mips_elf_got_section. (_bfd_mips_vxworks_finish_dynamic_symbol): Likewise. (_bfd_mips_elf_finish_dynamic_sections): Likewise. Move the initial assignment of G to the block that uses it; it is used for an unrelated purpose later. 2008-08-07 Richard Sandiford * elfxx-mips.c (count_section_dynsyms): Move before the new first use. (mips_elf_sort_hash_table): Take the output bfd as a parameter. Remove the MAX_LOCAL parameter. Exit early if there are no dynamic symbols, if there is no dynobj, or if there is no GOT section. Use count_section_dynsyms instead of MAX_LOCAL. Assert == rather than <= when checking hsd.max_unref_got_dynindx. Also assert that g->global_gotno is right. (mips_elf_count_forced_local_got_symbols): Rename to... (mips_elf_count_got_symbols): ...and count global GOT entries too. Set the global_got_area of a forced-local GGA_RELOC_ONLY symbol to GGA_NONE. (mips_elf_multi_got): Don't sort the symbol table. (mips_elf_lay_out_got): Likewise. Use mips_elf_count_got_symbols to count the number of global GOT entries. (_bfd_mips_elf_final_link): Unconditionally call mips_elf_sort_hash_table. 2008-08-07 Richard Sandiford * elfxx-mips.c (GGA_NORMAL, GGA_RELOC_ONLY, GGA_NONE): New macros. (mips_elf_link_hash_entry): Add a "global_got_area" field. (mips_elf_link_hash_newfunc): Initialize it. (mips_elf_sort_hash_table_f): Use h->global_got_area instead of h->root.got.offset. Do not handle forced_local symbols specially. (mips_elf_record_global_got_symbol): Set h->global_got_area instead of h->root.got.offset. (mips_elf_recreate_got): Assert that h->global_got_area == GGA_NONE for indirect and warning symbols. (mips_elf_count_forced_local_got_symbols): Change the argument
[Bug ld/10858] ld generate broken PIE binaries on MIPS
--- Additional Comments From aurelien at aurel32 dot net 2009-11-03 13:03 --- I have been able to bisect the bug further, here is the changeset that causes the problem: 2008-08-07 Richard Sandiford * elfxx-mips.c (mips_got_info): Add a "reloc_only_gotno" field. (mips_elf_got_section): Delete. (mips_elf_sort_hash_table): Use g->reloc_only_gotno to decide how many reloc-only entries there are. (mips_elf_count_got_symbols): Adjust g->reloc_only_gotno as well as g->global_gotno. (mips_elf_make_got_per_bfd): Initialize reloc_only_gotno. (mips_elf_multi_got): Likewise. Use gg->reloc_only_gotno rather than gg->assigned_gotno to store the number of reloc-only GOT entries. (mips_elf_create_got_section): Remove the MAYBE_EXCLUDE parameter. Initialize reloc_only_gotno. (mips_elf_calculate_relocation): Check htab->got_info instead of dynobj when deciding whether to call mips_elf_adjust_gp, (_bfd_mips_elf_create_dynamic_sections): Adjust the call to mips_elf_create_got_section. (mips_elf_record_relocs): Likewise. Remove redundant "dynobj == NULL" code. Do not use mips_elf_create_got_section or mips_elf_record_global_got_symbol for R_MIPS_32, R_MIPS_REL32 and R_MIPS_64; limit global_got_area to GGA_RELOC_ONLY instead. (_bfd_mips_elf_finish_dynamic_symbol): Use htab->sgot instead of mips_elf_got_section. (_bfd_mips_vxworks_finish_dynamic_symbol): Likewise. (_bfd_mips_elf_finish_dynamic_sections): Likewise. Move the initial assignment of G to the block that uses it; it is used for an unrelated purpose later. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10858 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10858] ld generate broken PIE binaries on MIPS
--- Additional Comments From aurelien at aurel32 dot net 2009-11-04 09:46 --- Thanks a lot for the patch, I confirm it works for both the versions just after the problem has been introduced and trunk. I also checked it introduces no regressions on the trunk version. I haven't tested your alternative patch yet, I will do that soon. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10858 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10858] ld generate broken PIE binaries on MIPS
--- Additional Comments From aurelien at aurel32 dot net 2009-11-04 10:47 --- The alternative patch also fixes the problem, and also doesn't introduce any regressions in the testsuite. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10858 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10144] mips/ld: non-dynamic relocations refer to dynamic symbol
--- Additional Comments From aurelien at aurel32 dot net 2010-08-23 18:43 --- This is indeed a gcc issue, marking the bug on ld as invalid. -- What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://sourceware.org/bugzilla/show_bug.cgi?id=10144 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10144] mips/ld: non-dynamic relocations refer to dynamic symbol
--- Additional Comments From aurelien at aurel32 dot net 2010-09-14 19:17 --- I am reopening the bug as it appeared that the issue is not fixed in GCC 4.5 as I wrongly said here. It's just that our gcc was configured to default to -mplt which, in some cases, workaround the issue. To summarize the issue: - The issue is reproducible with any gcc version (tested 4.1, 4.3, 4.4, 4.5), provided that you use a binutils from after 2008-08-09. binutils from before 2008-08-08 works find with the same versions of gcc. - The issue can always be workarounded by not using -g - The issue can sometimes be workarounded by using -mplt - The issue is not fixed in HEAD as of 2010-09-14. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://sourceware.org/bugzilla/show_bug.cgi?id=10144 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10144] mips/ld: non-dynamic relocations refer to dynamic symbol
--- Additional Comments From aurelien at aurel32 dot net 2010-09-14 19:24 --- Created an attachment (id=4981) --> (http://sourceware.org/bugzilla/attachment.cgi?id=4981&action=view) Testcase with C code and makefile This new testcase doesn't obsolete the previous ones, but it's probably more handy as it contains the C code and a Makefile -- http://sourceware.org/bugzilla/show_bug.cgi?id=10144 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10144] mips/ld: non-dynamic relocations refer to dynamic symbol
--- Additional Comments From aurelien at aurel32 dot net 2010-09-14 23:01 --- Thanks for working on that. I have also spend some time trying to understand the problem. I have also written a patch by analysing the difference with other architecture, so I am not really sure it is correct: --- a/elfxx-mips.c +++ b/elfxx-mips.c @@ -8341,6 +8339,11 @@ _bfd_mips_elf_adjust_dynamic_symbol (str if (h->def_regular) return TRUE; + /* If there are no references to this symbol that do not use the + GOT, we don't need to generate a copy reloc. */ + if (!h->non_got_ref) +return TRUE; + /* There's also nothing more to do if we'll convert all relocations against this symbol into dynamic relocations. */ if (!hmips->has_static_relocs) At least it fixes the issue. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10144 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10144] mips/ld: non-dynamic relocations refer to dynamic symbol
--- Additional Comments From aurelien at aurel32 dot net 2010-09-14 23:53 --- Thanks a lot for your work. I'll test it tomorrow on a few of the cases we have and keep you updated. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10144 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/10144] mips/ld: non-dynamic relocations refer to dynamic symbol
--- Additional Comments From aurelien at aurel32 dot net 2010-09-15 05:37 --- I have built binutils including the patch linked in the previous comment. I confirm it fixes all the problem we currently have wrt this issue. Thanks. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10144 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12606] New: [MIPS] relocation truncated to fit: R_MIPS_TLS_LDM
http://sourceware.org/bugzilla/show_bug.cgi?id=12606 Summary: [MIPS] relocation truncated to fit: R_MIPS_TLS_LDM Product: binutils Version: 2.22 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassig...@sources.redhat.com ReportedBy: aurel...@aurel32.net When trying to build libgcj.so from GCC 4.4, 4.5 or 4.6, ld from binutils 2.21 or HEAD is not able to do the final link and issue a "relocation truncated to fit: R_MIPS_TLS_LDM" message. The link succeed with ld from binutils 2.20 and the exact same objects. You will find below the link command that is used, and the corresponding error messages. I can provided a testcase, but please tell me what would be the best (tarball of all objects ?). /home/aurel32/gcj-4.5/gcj-4.5-4.5.2/build/./gcc/xgcc -shared-libgcc -B/home/aurel32/gcj-4.5/gcj-4.5-4.5.2/build/./gcc -nostdinc++ -L/home/aurel32/gcj-4.5/gcj-4.5-4.5.2/build/mipsel-linux-gnu/libstdc++-v3/src -L/home/aurel32/gcj-4.5/gcj-4.5-4.5.2/build/mipsel-linux-gnu/libstdc++-v3/src/.libs -B/usr/mipsel-linux-gnu/bin/ -B/usr/mipsel-linux-gnu/lib/ -isystem /usr/mipsel-linux-gnu/include -isystem /usr/mipsel-linux-gnu/sys-include -shared -nostdlib /usr/lib/../lib/crti.o /home/aurel32/gcj-4.5/gcj-4.5-4.5.2/build/./gcc/crtbeginS.o .libs/prims.o .libs/jni.o .libs/exception.o .libs/stacktrace.o .libs/link.o .libs/defineclass.o .libs/verify.o .libs/jvmti.o .libs/interpret.o gnu/classpath/jdwp/.libs/natVMFrame.o gnu/classpath/jdwp/.libs/natVMMethod.o gnu/classpath/jdwp/.libs/natVMVirtualMachine.o gnu/classpath/.libs/natConfiguration.o gnu/classpath/.libs/natSystemProperties.o gnu/classpath/.libs/natVMStackWalker.o gnu/gcj/.libs/natCore.o gnu/gcj/convert/.libs/JIS0208_to_Unicode.o gnu/gcj/convert/.libs/JIS0212_to_Unicode.o gnu/gcj/convert/.libs/Unicode_to_JIS.o gnu/gcj/convert/.libs/natIconv.o gnu/gcj/convert/.libs/natInput_EUCJIS.o gnu/gcj/convert/.libs/natInput_SJIS.o gnu/gcj/convert/.libs/natOutput_EUCJIS.o gnu/gcj/convert/.libs/natOutput_SJIS.o gnu/gcj/io/.libs/natSimpleSHSStream.o gnu/gcj/io/.libs/shs.o gnu/gcj/jvmti/.libs/natBreakpoint.o gnu/gcj/jvmti/.libs/natNormalBreakpoint.o gnu/gcj/runtime/.libs/natFinalizerThread.o gnu/gcj/runtime/.libs/natSharedLibLoader.o gnu/gcj/runtime/.libs/natSystemClassLoader.o gnu/gcj/runtime/.libs/natStringBuffer.o gnu/gcj/util/.libs/natDebug.o gnu/gcj/util/.libs/natGCInfo.o gnu/java/lang/.libs/natMainThread.o gnu/java/lang/management/.libs/natVMClassLoadingMXBeanImpl.o gnu/java/lang/management/.libs/natVMCompilationMXBeanImpl.o gnu/java/lang/management/.libs/natVMGarbageCollectorMXBeanImpl.o gnu/java/lang/management/.libs/natVMMemoryMXBeanImpl.o gnu/java/lang/management/.libs/natVMMemoryManagerMXBeanImpl.o gnu/java/lang/management/.libs/natVMMemoryPoolMXBeanImpl.o gnu/java/lang/management/.libs/natVMOperatingSystemMXBeanImpl.o gnu/java/lang/management/.libs/natVMRuntimeMXBeanImpl.o gnu/java/lang/management/.libs/natVMThreadMXBeanImpl.o gnu/java/net/.libs/natPlainDatagramSocketImpl.o gnu/java/net/.libs/natPlainSocketImpl.o gnu/java/net/protocol/core/.libs/natCoreInputStream.o gnu/java/nio/.libs/natVMPipe.o gnu/java/nio/.libs/natVMSelector.o gnu/java/nio/.libs/natNIOServerSocket.o gnu/java/nio/.libs/natVMChannel.o gnu/java/nio/channels/.libs/natFileChannelImpl.o gnu/java/security/jce/prng/.libs/natVMSecureRandom.o java/io/.libs/natFile.o java/io/.libs/natVMObjectInputStream.o java/io/.libs/natVMObjectStreamClass.o java/lang/.libs/natCharacter.o java/lang/.libs/natClass.o java/lang/.libs/natClassLoader.o java/lang/.libs/natConcreteProcess.o java/lang/.libs/natVMDouble.o java/lang/.libs/natVMFloat.o java/lang/.libs/natMath.o java/lang/.libs/natObject.o java/lang/.libs/natRuntime.o java/lang/.libs/natString.o java/lang/.libs/natAbstractStringBuffer.o java/lang/.libs/natSystem.o java/lang/.libs/natThread.o java/lang/.libs/natThreadLocal.o java/lang/.libs/natVMClassLoader.o java/lang/.libs/natVMProcess.o java/lang/.libs/natVMThrowable.o java/lang/ref/.libs/natReference.o java/lang/reflect/.libs/natArray.o java/lang/reflect/.libs/natConstructor.o java/lang/reflect/.libs/natField.o java/lang/reflect/.libs/natMethod.o java/lang/reflect/.libs/natVMProxy.o java/net/.libs/natVMInetAddress.o java/net/.libs/natVMNetworkInterface.o java/net/.libs/natVMURLConnection.o java/nio/channels/.libs/natVMChannels.o java/nio/.libs/natVMDirectByteBufferImpl.o java/security/.libs/natVMAccessController.o java/security/.libs/natVMAccessControlState.o java/text/.libs/natCollator.o java/util/.libs/natVMTimeZone.o java/util/concurrent/atomic/.libs/natAtomicLong.o java/util/logging/.libs/natLogger.o java/util/zip/.libs/natDeflater.o java/util/zip/.libs/natInflater.o sun/misc/.libs/natUnsafe.o .libs/boehm.o .libs/posix.o .libs/posix-threads.o java/lang/.libs/Object.o java/lang/.libs/Class.o java/.libs/process-Posix.o gnu/.libs/awt.o gnu/awt/.libs/j2d.o gnu/.libs/classpath.o gnu/classpath/.libs/debug.
[Bug ld/12606] [MIPS] relocation truncated to fit: R_MIPS_TLS_LDM
http://sourceware.org/bugzilla/show_bug.cgi?id=12606 Aurelien Jarno changed: What|Removed |Added Target||mipsel-unknown-linux-gnu Host||mipsel-unknown-linux-gnu Build||mipsel-unknown-linux-gnu -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12608] New: TLS relocations issues on alpha
http://sourceware.org/bugzilla/show_bug.cgi?id=12608 Summary: TLS relocations issues on alpha Product: binutils Version: 2.21 Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassig...@sources.redhat.com ReportedBy: aurel...@aurel32.net Host: alphaev68-unknown-linux-gnu Target: alphaev68-unknown-linux-gnu Build: alphaev68-unknown-linux-gnu Some TLS glibc tests fail on alpha when built with gcc -mtune=ev5 or later CPU. Digging into the issues, it seems the problem comes from the linker. The problem affects tst-tlsmod7.c and tst-tlsmod8.c. When built with -mtune=ev5, some instructions are re-ordered, which seems to confuse ld. Let's give the example of tst-tlsmod7. I have attached the corresponding source code to this bug report, it's possible to build the .so with "gcc -shared tst-tlsmod7.s -o tst-tlsmod7.so". The difference at the source level causing the issue between -mtune=ev4 and -mtune=ev5 is the following: --- tst-tlsmod7.ev4.s +++ tst-tlsmod7.ev5.s @@ -429,8 +429,8 @@ cmpeq $1,27,$1 beq $1,$L36 .loc 1 26 0 - lda $16,local1($29) !tlsldm!29 ldq $27,__tls_get_addr($29) !literal!29 + lda $16,local1($29) !tlsldm!29 jsr $26,($27),__tls_get_addr!lituse_tlsldm!29 ldah $29,0($26) !gpdisp!31 ldah $0,local1($0) !dtprelhi When looking at the corresponding .o, the difference is still the same: --- tst-tlsmod7.ev4.o +++ tst-tlsmod7.ev5.o @@ -295,10 +295,10 @@ 318: 08 00 21 a4 ldq t0,8(t0) 31c: a1 75 23 40 cmpeq t0,0x1b,t0 320: 21 00 20 e4 beq t0,3a8 - 324: 00 00 1d 22 lda a0,0(gp) - 324: TLSLDM local1 - 328: 00 00 7d a7 ldq t12,0(gp) - 328: ELF_LITERAL__tls_get_addr + 324: 00 00 7d a7 ldq t12,0(gp) + 324: ELF_LITERAL__tls_get_addr + 328: 00 00 1d 22 lda a0,0(gp) + 328: TLSLDM local1 32c: 00 40 5b 6b jsr ra,(t12),330 32c: LITUSE .text+0x5 32c: HINT __tls_get_addr When looking at the corresponding .so, the difference has now changed, probably due to a relocation issue in the linker: --- tst-tlsmod7.ev4.so +++ tst-tlsmod7.ev5.so @@ -744,7 +744,7 @@ d38: 08 00 21 a4 ldq t0,8(t0) d3c: a1 75 23 40 cmpeq t0,0x1b,t0 d40: 21 00 20 e4 beq t0,dc8 - d44: 58 80 1d a6 ldq a0,-32680(gp) + d44: 58 80 7d a7 ldq t12,-32680(gp) d48: 00 00 fe 2f unop d4c: 9e 00 00 00 rduniq d50: 00 04 00 42 addqa0,v0,v0 The value is now loaded into t12 instead of a0, which gives a segfault when this address is used a bit later. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12608] TLS relocations issues on alpha
http://sourceware.org/bugzilla/show_bug.cgi?id=12608 --- Comment #1 from Aurelien Jarno 2011-03-27 17:06:32 UTC --- Created attachment 5328 --> http://sourceware.org/bugzilla/attachment.cgi?id=5328 working source code (EV4) -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12608] TLS relocations issues on alpha
http://sourceware.org/bugzilla/show_bug.cgi?id=12608 --- Comment #2 from Aurelien Jarno 2011-03-27 17:07:02 UTC --- Created attachment 5329 --> http://sourceware.org/bugzilla/attachment.cgi?id=5329 broken source code (EV5) -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12845] New: ld segfaults when using
http://sourceware.org/bugzilla/show_bug.cgi?id=12845 Summary: ld segfaults when using Product: binutils Version: 2.22 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassig...@sources.redhat.com ReportedBy: aurel...@aurel32.net Host: mips-unknown-linux-gnu Target: mips-unknown-linux-gnu Build: mips-unknown-linux-gnu When linking udev on mips, ld segfaults if --gc-sections is used (which is the default in the recent versions). Here is the corresponding backtrace, it seems osec->used_by_bfd equals to NULL, so the segfaults appear when dereferencing osec->used_by_bfd->this_hdr.sh_type. This happens with binutils from HEAD. (gdb) bt #0 0x00481840 in _bfd_elf_init_private_section_data (ibfd=, isec=0x806d10, obfd=0x5da970, osec=0x5c4db8, link_info=0x5cb658) at elf.c:6279 #1 0x00411588 in lang_add_section (ptr=0x7fd410f8, section=0x806d10, output=0x5cc580) at ldlang.c:2360 #2 0x0042b534 in mips_add_stub_section (stub_sec_name=0x79a638 ".text.stub.1", input_section=0x778448, output_section=0x5c4db8) at eelf32btsmip.c:263 #3 0x00463a98 in mips_elf_add_la25_intro (h=, data=0x7fd411e0) at elfxx-mips.c:1599 #4 mips_elf_add_la25_stub (h=, data=0x7fd411e0) at elfxx-mips.c:1710 #5 mips_elf_check_symbols (h=, data=0x7fd411e0) at elfxx-mips.c:1740 #6 0x0044cbf0 in bfd_hash_traverse (table=0x5dcb98, func=0x463694 , info=0x7fd411e0) at hash.c:656 #7 0x0046a084 in _bfd_mips_elf_always_size_sections (output_bfd=0x5da970, info=0x5cb658) at elfxx-mips.c:8428 #8 0x0049718c in bfd_elf_size_dynamic_sections (output_bfd=0x5da970, soname=0x0, rpath=0x0, filter_shlib=0x0, audit=0x0, depaudit=0x0, auxiliary_filters=0x0, info=0x5cb658, sinterpptr=0x7fd41318, verdefs=0x0) at elflink.c:5598 #9 0x0042b828 in gldelf32btsmip_before_allocation () at eelf32btsmip.c:1598 #10 mips_before_allocation () at eelf32btsmip.c:299 #11 0x00416670 in lang_process () at ldlang.c:6653 #12 0x00402e34 in main (argc=21, argv=0x7fd41534) at ./ldmain.c:462 (gdb) print osec->used_by_bfd $1 = (void *) 0x0 -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/12845] ld segfaults when using
http://sourceware.org/bugzilla/show_bug.cgi?id=12845 --- Comment #1 from Aurelien Jarno 2011-06-05 21:57:42 UTC --- Created attachment 5768 --> http://sourceware.org/bugzilla/attachment.cgi?id=5768 tarball containing objects to reproduce the issue Run testcase.sh to reproduce the issue. Note that removing --gc-sections will make the link to fail, as I removed all .o that were not necessary to make the segfault happen (in order to keep the sire reasonable). -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/12845] ld segfaults when using
http://sourceware.org/bugzilla/show_bug.cgi?id=12845 --- Comment #4 from Aurelien Jarno 2011-06-09 06:28:54 UTC --- Hi Nick, Thanks a lot for the quick patch, I confirm that it fixes the issue I reported. Cheers, Aurelien -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/12845] ld segfaults when using
http://sourceware.org/bugzilla/show_bug.cgi?id=12845 --- Comment #7 from Aurelien Jarno 2011-06-09 10:54:31 UTC --- Thanks! -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/12978] New: ld generates broken ld.so on ia64
http://sourceware.org/bugzilla/show_bug.cgi?id=12978 Summary: ld generates broken ld.so on ia64 Product: binutils Version: 2.22 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassig...@sources.redhat.com ReportedBy: aurel...@aurel32.net Host: ia64-unknown-linux-gnu Target: ia64-unknown-linux-gnu Build: ia64-unknown-linux-gnu ld from binutils HEAD produces broken ld.so on ia64. The resulting binary works when called as a standalone, but just segfaults when used with other binaries: | $ ./ld.so | Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...] | You have invoked `ld.so', the helper program for shared library executables. | This program usually lives in the file `/lib/ld.so', and special directives | in executable files using ELF shared libraries tell the system's program | loader to load the helper program from this file. This helper program loads | the shared libraries needed by the program executable, prepares the program | to run, and runs it. You may invoke this helper program directly from the | command line to load and run an ELF executable file; this is like executing | that file itself, but always uses this helper program from the file you | specified, instead of the helper program file specified in the executable | file you run. This is mostly of use for maintainers to test new versions | of this helper program; chances are you did not intend to run this program. | | --listlist all dependencies and how they are resolved | --verify verify that given object really is a dynamically linked | object we can handle | --library-path PATH use given PATH instead of content of the environment | variable LD_LIBRARY_PATH | --inhibit-rpath LIST ignore RUNPATH and RPATH information in object names | in LIST | --audit LIST use objects named in LIST as auditors | $ ./ld.so /bin/ls | Segmentation fault The issue has been introduced by the following changes: | 2011-05-25 Tristan Gingold | | * configure.in (bfd_elf32_ia64_big_vec, bfd_elf32_ia64_hpux_big_vec) | (bfd_elf64_ia64_big_vec, bfd_elf64_ia64_hpux_big_vec) | (bfd_elf64_ia64_little_vec, bfd_elf64_ia64_vms_vec): Add elfxx-ia64.lo | * Makefile.am (BFD64_BACKENDS): Add elfxx-ia64.lo | (BFD64_BACKENDS_CFILES): Add elfxx-ia64.c | (elf32-ia64.c): Created from elfnn-ia64.c | (elf64-ia64.c): Likewise. | * elfxx-ia64.h: New file. | * elfxx-ia64.c: Split with elfnn-ia64.c. Keep only the following | functions.Includes elfxx-ia64.h. | (elfNN_ia64_reloc): Renames to ia64_elf_reloc. Adjust error message. | (IA64_HOWTO): Adjust. | (lookup_howto): Renames to ia64_elf_lookup_howto. Make it public. | (elfNN_ia64_reloc_type_lookup): Renames to | ia64_elf_reloc_type_lookup. Make it public. Adjust calls. | (elfNN_ia64_reloc_name_lookup): Renames to | ia64_elf_reloc_name_lookup. Make it public. | (elfNN_ia64_relax_br): Renames to ia64_elf_relax_br. Make it public. | (elfNN_ia64_relax_brl): Renames to ia64_elf_relax_brl. Make it | public. | (elfNN_ia64_relax_ldxmov): Renames to ia64_elf_relax_ldxmov. | Move it and make it public. Move prototype to elfxx-ia64.h | (elfNN_ia64_install_value): Renames to ia64_elf_install_value. | Move prototype to elfxx-ia64.h | * elfnn-ia64.c: New file, split from elfxx-ia64.c. | (elfNN_ia64_info_to_howto): Adjust calls. | (elfNN_ia64_relax_section): Adjust calls. | (count_dyn_reloc): Fix typo. | (elfNN_ia64_relocate_section): Adjust calls. | (elfNN_ia64_finish_dynamic_symbol): Likewise. | (bfd_elfNN_bfd_reloc_type_lookup) | (bfd_elfNN_bfd_reloc_name_lookup): Adjust macros. | * configure: Regenerate. | * Makefile.in: Regenerate. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/12978] ld generates broken ld.so on ia64
http://sourceware.org/bugzilla/show_bug.cgi?id=12978 --- Comment #1 from Aurelien Jarno 2011-07-09 16:51:51 UTC --- Created attachment 5841 --> http://sourceware.org/bugzilla/attachment.cgi?id=5841 Testcase to reproduce the issue Please find attached a tarball to reproduce the issue. Run ./testcase.sh, which should just print the libc.so help with a non-broken binutils or should segfault with a broken binutils. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/12978] ld generates broken ld.so on ia64
http://sourceware.org/bugzilla/show_bug.cgi?id=12978 --- Comment #3 from Aurelien Jarno 2011-07-17 22:08:39 UTC --- I confirm it fixes the issue. Thanks for the quick work. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/13024] New: Internal error on mips/mipsel
http://sourceware.org/bugzilla/show_bug.cgi?id=13024 Summary: Internal error on mips/mipsel Product: binutils Version: 2.22 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gas AssignedTo: unassig...@sources.redhat.com ReportedBy: aurel...@aurel32.net Host: mips-unknown-linux-gnu Target: mips-unknown-linux-gnu Build: mips-unknown-linux-gnu Created attachment 5861 --> http://sourceware.org/bugzilla/attachment.cgi?id=5861 T Recent changes to gas (20110629 is ok, 20110707 is not), makes it unable to compile certain files: testcase.s: Assembler messages: testcase.s: Internal error! Assertion failure in emit_inc_line_addr at dwarf2dbg.c line 926. Please report this bug. I have attached a testcase to reproduce the issue, but while the bug appears on both mips and mipsel, it seems the testcase itself is endianness specific. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/13024] Internal error on mips/mipsel
http://sourceware.org/bugzilla/show_bug.cgi?id=13024 --- Comment #4 from Aurelien Jarno 2011-09-08 14:24:32 UTC --- I confirm this fixes the issue, thanks a lot for working on that. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- 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/32572] New: -z force-bti + -Ttext-segment produce wrong PLT entries on aarch64
https://sourceware.org/bugzilla/show_bug.cgi?id=32572 Bug ID: 32572 Summary: -z force-bti + -Ttext-segment produce wrong PLT entries on aarch64 Product: binutils Version: 2.44 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: aurelien at aurel32 dot net Target Milestone: --- Host: aarch64-unknown-linux-gnu Target: aarch64-unknown-linux-gnu Build: aarch64-unknown-linux-gnu The future glibc 2.41 added two new tests, elf/tst-pie-address and elf/tst-pie-address-static, that fail when enabling PAC/BTI on aarch64. Further investigation by Adhemerval Zanella Netto [2] shows that ld generate wrong plt entries when -z force-bti and -Ttext-segment options are used together: * default options 12e0 : 12e0: f0f0adrpx16, 2 12e4: f9400211ldr x17, [x16] 12e8: 91000210add x16, x16, #0x0 12ec: d61f0220br x17 * with -Ttext-segment=0x0040 004012e0 : 4012e0: f0f0adrpx16, 42 4012e4: f9400211ldr x17, [x16] 4012e8: 91000210add x16, x16, #0x0 4012ec: d61f0220br x17 * with -z force-bti 1370 : 1370: f0f0adrpx16, 2 1374: f9400211ldr x17, [x16] 1378: 91000210add x16, x16, #0x0 137c: d61f0220br x17 * with -z force-bti + -Ttext-segment=0x0040 00401370 : 401370: 9010adrpx16, 401000 <_init-0x328> 401374: f9f1str x17, [x7] 401378: 91000210add x16, x16, #0x0 40137c: d6000220.inst 0xd6000220 ; undefined 401380: 9010adrpx16, 401000 <_init-0x328> 401384: f9f1str x17, [x7] [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=e7b553272196e6175b8a15f807cb59217ba2843a [2] https://sourceware.org/pipermail/libc-alpha/2025-January/164046.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32572] -z force-bti + -Ttext-segment produce wrong PLT entries on aarch64
https://sourceware.org/bugzilla/show_bug.cgi?id=32572 --- Comment #4 from Aurelien Jarno --- (In reply to H.J. Lu from comment #2) > Created attachment 15888 [details] > A patch > > Please try this. Thanks for the patch. I have built binutils with it and I do not see any regression in the testsuite. That said building glibc with that patches binutils seems to produce broken binaries, for example iconv just generates a SIGILL. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32671] Default to erroring out on executable stacks
https://sourceware.org/bugzilla/show_bug.cgi?id=32671 --- Comment #7 from Aurelien Jarno --- (In reply to Florian Weimer from comment #6) > (In reply to Aurelien Jarno from comment #5) > > I am not fully convince that we want to default to > > --enable-error-execstack=yes at this stage. It seems that there are cases > > where GCC generate code with nested functions, and I am not sure how much > > widespread is that, i have found at least one case. It seems that > > -ftrampoline-impl=heap is a workaround on some architectures, but I am not > > sure about the consequences. > > > See comment 2. In these cases, there will be markup, and it explicitly > requests an executable stack. The problematic cases are not that, it's > inputs that are not marked up at all. Thanks, indeed I misunderstood the option, it looks clearer after looking at the documentation. Overall I have mixed feeling about it. So far I have seen three main cases causing a missing .note.GNU-stack: - asm code missing the .note.GNU-stack. In that case I think it makes sense to error out (although some projects like onnxruntime target more than GNU systems and prefer to force -znoexecstack at link time on GNU systems rather than changing the asm code) - embedding data in the binary using "ld -r -b binary". Currently this command does not even emit a warning, I think it would make sense to just automatically add a .note.GNU-stack in that case instead of having to patch all of those commands to also pass -z noexecstack. - Use of llvm-mc. I haven't yet understood all the details, this command as a -no-exec-stack option but it is not the default. For the two first cases, defaulting to non executable stack when .note.GNU-stack is missing would just fix everything. Changing that into an error means a lot of code has to be patched. For the last case, at least with my current understanding, both options require patching code. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32671] Default to erroring out on executable stacks
https://sourceware.org/bugzilla/show_bug.cgi?id=32671 Aurelien Jarno changed: What|Removed |Added CC||aurelien at aurel32 dot net --- Comment #5 from Aurelien Jarno --- IMHO, i think that binutils-2.45 should default to: - non-executable stack when there is no .note.GNU-stack (--disable-default-execstack) - warn in case of executable stack (--enable-warn-execstack=yes) I believe that --enable-warn-rwx-segments=yes is also fine. Note however that this causes regression in the testsuite (see PR32715). I am not fully convince that we want to default to --enable-error-execstack=yes at this stage. It seems that there are cases where GCC generate code with nested functions, and I am not sure how much widespread is that, i have found at least one case. It seems that -ftrampoline-impl=heap is a workaround on some architectures, but I am not sure about the consequences. -- You are receiving this mail because: You are on the CC list for the bug.
