[Bug ld/23470] ld.bfd occasionally segfaults after running out of memory on 32-bit x86
https://sourceware.org/bugzilla/show_bug.cgi?id=23470 --- Comment #7 from A. Wilcox --- What is the best way to provide you with all linker input? I could make a full tarball of the builder chroot, but it would be many gigabytes, even compressed. The issue is, after all, trying to link nearly 4 GB of object files. You can likely duplicate the issue yourself by making an Adélie chroot on an x86 (or x86_64), installing build-tools, checking out packages.git, and then building user/qt5-qtwebkit, but that is of course a lot of steps and would require a significant amount of time. Would shell access to a builder work? As for the linker command line, please give me a few hours. We are trying to solve other issues on that builder right now (specifically https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84823 at the moment) and it is tied up with that. -- 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/23463] FAIL: PR ld/12982
https://sourceware.org/bugzilla/show_bug.cgi?id=23463
--- Comment #3 from dave.anglin at bell dot net ---
Hi Nick,
On 2018-08-01 5:02 AM, nickc at redhat dot com wrote:
>I have applied the obvious fix to the pr12982 test for the HPPA target.
The fix didn't work:
Executing on host: sh -c {gcc
-B/home/dave/gnu/binutils/objdir/ld/tmpdir/ld/ -
L=/home/dave/opt/gnu/hppa-unknown-linux-gnu/lib
-L=/home/dave/opt/gnu/lib -L=/us
r/local/lib -L=/lib -L=/usr/lib -o tmpdir/pr12982.exe
-L/home/dave/gnu/binutil
s/src/ld/testsuite/ld-plugin -O2 -flto -fuse-linker-plugin
tmpdir/pr12982.o 2>&1
} /dev/null ld.tmp (timeout = 300)
spawn [open ...]
/home/dave/gnu/binutils/objdir/ld/../binutils/readelf -l --wide
tmpdir/pr12982.e
xe > dump.out
fail if no difference
FAIL: PR ld/12982
Dave
--
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/23471] [2.31.1, regression] /usr/bin/objcopy: memory exhausted on m68k
https://sourceware.org/bugzilla/show_bug.cgi?id=23471 --- Comment #6 from John Paul Adrian Glaubitz --- I have filed #86820 now: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86820 -- 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/23471] [2.31.1, regression] /usr/bin/objcopy: memory exhausted on m68k
https://sourceware.org/bugzilla/show_bug.cgi?id=23471 John Paul Adrian Glaubitz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from John Paul Adrian Glaubitz --- (In reply to Nick Clifton from comment #4) > (In reply to John Paul Adrian Glaubitz from comment #3) > > Phew! Well that is good to hear as I was dreading trying to bisect this one. That was actually what I was just going through :-). I kept checking out older major revisions and the problem would still reproduce such that at some point I dropped the idea of binutils being to be blamed here. > Would you mind closing this PR and opening a gcc one instead please ? Absolutely. -- 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/23471] [2.31.1, regression] /usr/bin/objcopy: memory exhausted on m68k
https://sourceware.org/bugzilla/show_bug.cgi?id=23471 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #4 from Nick Clifton --- (In reply to John Paul Adrian Glaubitz from comment #3) Phew! Well that is good to hear as I was dreading trying to bisect this one. Would you mind closing this PR and opening a gcc one instead please ? 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/23463] FAIL: PR ld/12982
https://sourceware.org/bugzilla/show_bug.cgi?id=23463 Nick Clifton changed: What|Removed |Added Status|NEW |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Hi John, I have applied the obvious fix to the pr12982 test for the HPPA target. I have not made a change for the MIPS target as I think that it would be better to have a MIPSy type person confirm that it is needed first. 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/23463] FAIL: PR ld/12982
https://sourceware.org/bugzilla/show_bug.cgi?id=23463 --- 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=e30985fa2b495a6b932e1376f287cb51252572d7 commit e30985fa2b495a6b932e1376f287cb51252572d7 Author: Nick Clifton Date: Wed Aug 1 15:28:37 2018 +0100 Skip the test for PR12982 on HPPA targets as they always need an executable stack. PR 23463 * testsuite/ld-plugin/pr12982.d: Skip thios test for the HPPA target. -- 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/23471] [2.31.1, regression] /usr/bin/objcopy: memory exhausted on m68k
https://sourceware.org/bugzilla/show_bug.cgi?id=23471 --- Comment #3 from John Paul Adrian Glaubitz --- I have narrowed it down to being a compiler bug. The problem shows with binutils built with gcc-8. Building the same version with gcc-7 makes the problem go away and strip works correctly again. -- 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/14480] PDP11 gas generates invalid code for deferred indirect JSR with 0 index
https://sourceware.org/bugzilla/show_bug.cgi?id=14480 Nick Clifton changed: What|Removed |Added Status|NEW |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #9 from Nick Clifton --- Hi James, Thanks for the patch. I have applied it, along with an addition to the PDP11 assembler testsuite, to the mainline sources. I did make one addition to the patch. Just a small paranoia check to make sure that the bytes between str[1] and str[5] are not NUL. 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/14480] PDP11 gas generates invalid code for deferred indirect JSR with 0 index
https://sourceware.org/bugzilla/show_bug.cgi?id=14480 --- Comment #8 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=3cf2b6691cef024f7cdb48aaec5fab5189e1cffa commit 3cf2b6691cef024f7cdb48aaec5fab5189e1cffa Author: James Patrick Conlon Date: Wed Aug 1 15:14:46 2018 +0100 Fix bug in PDP11 assembler when handling a JSr instruction with deferred auto increment. PR 14480 * config/tc-pdp11.c (parse_op_noreg): Check for and handle auto increment deferred. * testsuite/gas/pdp11/pr14480.d: New test driver file. * testsuite/gas/pdp11/pr14480.s: New test source file file. * testsuite/gas/pdp11/pdp11.exp: Run the new test. -- 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/23460] regression: ar can not create archive containing many (>1024) lto object files
https://sourceware.org/bugzilla/show_bug.cgi?id=23460 --- Comment #7 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=103da91bc083f94769e3758175a96d06cef1f8fe commit 103da91bc083f94769e3758175a96d06cef1f8fe Author: Nick Clifton Date: Wed Aug 1 14:34:41 2018 +0100 Close resource leaks in the BFD library's plugin handler. PR 23460 * plugin.c (bfd_plugin_open_input): Close file descriptor if the call to fstat fails. (try_claim): Always close the file descriptor at the end of the function. (try_load_plugin): If a plugin has already been registered, then skip the dlopen and onload steps and go straight to claiming the file. If these is an error, close the plugin. -- 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/23460] regression: ar can not create archive containing many (>1024) lto object files
https://sourceware.org/bugzilla/show_bug.cgi?id=23460 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #8 from Nick Clifton --- Thanks for the patches. I have applied them along with an extra fix to try_load_plugin() to close the plugin if it was unable to claim the file. -- 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/23470] ld.bfd occasionally segfaults after running out of memory on 32-bit x86
https://sourceware.org/bugzilla/show_bug.cgi?id=23470 --- Comment #6 from Alan Modra --- I meant "is not as useful" -- 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/23470] ld.bfd occasionally segfaults after running out of memory on 32-bit x86
https://sourceware.org/bugzilla/show_bug.cgi?id=23470 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #5 from Alan Modra --- Please do show the linker command line. A ld bug report without the ld invocation is as useful as it could be. ld of course ought to exit after hitting OOM, but there are places where ld ignores an error status and continues on. One such place is the bfd_gc_sections call in ldlang.c. -- 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/23470] ld.bfd occasionally segfaults after running out of memory on 32-bit x86
https://sourceware.org/bugzilla/show_bug.cgi?id=23470 --- Comment #4 from H.J. Lu --- (In reply to A. Wilcox from comment #3) > Same result/output using that tree, though it seems to segfault more > reliably now (instead of just quitting with Memory exhausted). If you can provide ALL linker input, I will take a look. -- 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/23471] [2.31.1, regression] /usr/bin/objcopy: memory exhausted on m68k
https://sourceware.org/bugzilla/show_bug.cgi?id=23471
--- Comment #2 from John Paul Adrian Glaubitz ---
Here's the strace output for when strip fails:
execve("/usr/bin/strip", ["strip", "json2yaml"], 0xefc34d4c /* 18 vars */) = 0
brk(NULL) = 0x80024000
uname({sysname="Linux", nodename="pacman", ...}) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=57724, ...}) = 0
mmap2(NULL, 57724, PROT_READ, MAP_PRIVATE, 3, 0) = 0xc002
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/m68k-linux-gnu/libbfd-2.31.1-system.so",
O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\4\0\0\0\1\0\1\343\240\0\0\0004"..., 512)
= 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=674200, ...}) = 0
mmap2(NULL, 698280, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xc002f000
mprotect(0xc00ca000, 12288, PROT_NONE) = 0
mmap2(0xc00cd000, 36864, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x9c000) = 0xc00cd000
mmap2(0xc00d6000, 14248, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xc00d6000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/m68k-linux-gnu/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\4\0\0\0\1\0\0$\330\0\0\0004"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=100268, ...}) = 0
mmap2(NULL, 107084, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xc00da000
mprotect(0xc00f2000, 4096, PROT_NONE) = 0
mmap2(0xc00f3000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0xc00f3000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/m68k-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\4\0\0\0\1\0\0\16\0\0\0\0004"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=9800, ...}) = 0
mmap2(NULL, 16712, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xc00f5000
mprotect(0xc00f7000, 4096, PROT_NONE) = 0
mmap2(0xc00f8000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0xc00f8000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/m68k-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\4\0\0\0\1\0\2\22\34\0\0\0004"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1314240, ...}) = 0
mmap2(NULL, 1326676, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xc00fa000
mprotect(0xc0233000, 12288, PROT_NONE) = 0
mmap2(0xc0236000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13a000) = 0xc0236000
mmap2(0xc023c000, 7764, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xc023c000
close(3)= 0
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xc001b000
set_thread_area(0xc0022dd0) = 0
mprotect(0xc0236000, 8192, PROT_READ) = 0
mprotect(0xc00f8000, 4096, PROT_READ) = 0
mprotect(0xc00f3000, 4096, PROT_READ) = 0
mprotect(0xc00cd000, 24576, PROT_READ) = 0
mprotect(0x80021000, 4096, PROT_READ) = 0
mprotect(0xc001d000, 4096, PROT_READ) = 0
munmap(0xc002, 57724) = 0
get_thread_area() = 0xc0022dd0
get_thread_area() = 0xc0022dd0
get_thread_area() = 0xc0022dd0
get_thread_area() = 0xc0022dd0
get_thread_area() = 0xc0022dd0
get_thread_area() = 0xc0022dd0
get_thread_area() = 0xc0022dd0
get_thread_area() = 0xc0022dd0
get_thread_area() = 0xc0022dd0
get_thread_area() = 0xc0022dd0
get_thread_area() = 0xc0022dd0
get_thread_area() = 0xc0022dd0
get_thread_area() = 0xc0022dd0
get_thread_area() = 0xc0022dd0
get_thread_area() = 0xc0022dd0
get_thread_area() = 0xc0022dd0
get_thread_area() = 0xc0022dd0
get_thread_area() = 0xc0022dd0
get_thread_area() = 0xc0022dd0
get_thread_area() = 0xc0022dd0
brk(NULL) = 0x80024000
brk(0x80045000) = 0x80045000
get_thread_area() = 0xc0022dd0
get_thread_area()
[Bug binutils/23471] [2.31.1, regression] /usr/bin/objcopy: memory exhausted on m68k
https://sourceware.org/bugzilla/show_bug.cgi?id=23471 --- Comment #1 from John Paul Adrian Glaubitz --- This shows the regression: Version 2.31.1-2 in Debian: (sid-m68k-sbuild)root@nofan:/tmp# strip json2yaml /usr/bin/strip:json2yaml: memory exhausted (sid-m68k-sbuild)root@nofan:/tmp# Downgrading to an older version: (sid-m68k-sbuild)root@nofan:/tmp# apt install binutils-common=2.30.90.20180710-1 binutils=2.30.90.20180710-1 libbinutils=2.30.90.20180710-1 binutils-m68k-linux-gnu=2.30.90.20180710-1 And: (sid-m68k-sbuild)root@nofan:/tmp# strip json2yaml (sid-m68k-sbuild)root@nofan:/tmp# I could not reproduce it with a cross-binutils on amd64. The binary has to be quite large in order to be able to reproduce the problem: (sid-m68k-sbuild)root@nofan:/tmp# ls -l *yaml* -rwxr-xr-x 1 root root 43823968 Aug 1 09:29 json2yaml -rwxr-xr-x 1 root root 31365076 Aug 1 09:29 yaml2json (sid-m68k-sbuild)root@nofan:/tmp# strip yaml2json (sid-m68k-sbuild)root@nofan:/tmp# strip json2yaml /usr/bin/strip:json2yaml: memory exhausted (sid-m68k-sbuild)root@nofan:/tmp# -- 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/23471] New: [2.31.1, regression] /usr/bin/objcopy: memory exhausted on m68k
https://sourceware.org/bugzilla/show_bug.cgi?id=23471 Bug ID: 23471 Summary: [2.31.1, regression] /usr/bin/objcopy: memory exhausted on m68k Product: binutils Version: 2.31 URL: https://buildd.debian.org/status/fetch.php?pkg=wiresha rk=m68k=2.6.2-2=1533058050=0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: glaubitz at physik dot fu-berlin.de CC: doko at debian dot org, jrtc27 at jrtc27 dot com, sch...@linux-m68k.org Target Milestone: --- Target: m68k-*-* The recent branch updates for 2.31.1 has resulted in a regression on m68k with tools like objcopy and strip running out of memory. Building wireshark on Debian m68k fails with: dh_strip --ddeb-migration="wireshark-dbg (<< 2.0.1+g59ea380-12.0.1+g59ea380-2~)" || dh_strip /usr/bin/objcopy:debian/libwireshark11/usr/lib/m68k-linux-gnu/libwireshark.so.11.1.2: memory exhausted dh_strip: objcopy --only-keep-debug --compress-debug-sections debian/libwireshark11/usr/lib/m68k-linux-gnu/libwireshark.so.11.1.2 debian/.debhelper/libwireshark11/dbgsym-root/usr/lib/debug/.build-id/8d/574eed1bdf861517258e43eb7c77408493c40e.debug returned exit code 1 dh_strip: Aborting due to earlier error /usr/bin/objcopy:debian/libwireshark11/usr/lib/m68k-linux-gnu/libwireshark.so.11.1.2: memory exhausted dh_strip: objcopy --only-keep-debug --compress-debug-sections debian/libwireshark11/usr/lib/m68k-linux-gnu/libwireshark.so.11.1.2 debian/.debhelper/libwireshark11/dbgsym-root/usr/lib/debug/.build-id/8d/574eed1bdf861517258e43eb7c77408493c40e.debug returned exit code 1 dh_strip: Aborting due to earlier error Full log: https://buildd.debian.org/status/fetch.php?pkg=wireshark=m68k=2.6.2-2=1533058050=0 Building haskell-yaml on Debian m68k fails with: debian/hlibrary.setup copy --builddir=dist-ghc --destdir=debian/tmp-inst-ghc Installing library in debian/tmp-inst-ghc/usr/lib/haskell-packages/ghc/lib/m68k-linux-ghc-8.2.2/yaml-0.8.31.1-EX4SEGT1sRZ4D4BySsFjv1 Installing executable yaml2json in debian/tmp-inst-ghc/usr/bin Warning: The directory debian/tmp-inst-ghc/usr/bin is not in the system search path. /usr/bin/strip:debian/tmp-inst-ghc/usr/bin/yaml2json: memory exhausted make: *** [/usr/share/cdbs/1/class/hlibrary.mk:188: debian/tmp-inst-ghc] Error 1 Full log: https://buildd.debian.org/status/fetch.php?pkg=haskell-yaml=m68k=0.8.31.1-1=1533003205=0 -- 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
