[Bug ld/22831] ld causes massive thrashing if object files are not fully memory-resident: new algorithm needed
https://sourceware.org/bugzilla/show_bug.cgi?id=22831 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #25 from Ian Lance Taylor --- When using gold the key options are --no-mmap-output-file --no-map-whole-files --no-keep-files-mapped. Can you confirm that those options--all of them together--were tried with gold? -- 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/22831] ld causes massive thrashing if object files are not fully memory-resident: new algorithm needed
https://sourceware.org/bugzilla/show_bug.cgi?id=22831 --- Comment #24 from Luke Kenneth Casson Leighton --- hiya nick, thanks for trying out the torture program. basically the parameters there generate a 6.1mb object file (with gcc 7.3), and 3000x that equals an 18 gbytes executable. so, it's possible to work out what needs to be done: increase the 2nd or 3rd parameter directly proportionately so as to ensure that the object file increases to where the available RAM will be exceeded. regarding ld-gold: https://lists.debian.org/debian-devel/2019/01/msg00069.html so no, it doesn't work. mike hommey tried gnu gold for firefox on debian 32-bit: everything he's tried has failed. that leaves cross-compiling using a 64-bit system as literally *the* only option (which is completely unacceptable as a band-aid "solution") regarding "-g -g -g": it increases the amount of debug information, and consequently is a quick-hack way to increase the size of the output binary. regarding the evil idea of letting the limit be hit and weeding out applications that try it, on the basis that it's pretty insane to have such massive static executables: i really like it :) ... except... the first casualty is already being hit, and that's *all* 32-bit hardware. armhf, armel, i686, MIPS32 and a few more besides. all distros supporting 32-bit hardware are currently going through hell, and/or are *DROPPING* 32-bit support entirely, whilst 64-bit hardware continues to "accept" the insane inexorable increase in static executable size. so, perfectly good 32-bit hardware is being thrown into landfill because there's absolutely no way they can get hold of a modern distro that works on it... ... all because of this one bug that dates back to a short-sighted decision from the late 1990s. hence why i raised this to priority one critical level a couple of days ago. -- 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/24076] LWPINS not handled correctly in Intel syntax
https://sourceware.org/bugzilla/show_bug.cgi?id=24076 Andreas Abel changed: What|Removed |Added CC||abel at cs dot uni-saarland.de -- 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/24076] New: LWPINS not handled correctly in Intel syntax
https://sourceware.org/bugzilla/show_bug.cgi?id=24076 Bug ID: 24076 Summary: LWPINS not handled correctly in Intel syntax Product: binutils Version: 2.31 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: abel at cs dot uni-saarland.de Target Milestone: --- For the instruction "lwpins rax,DWORD PTR [rax],0x1", gas reports "Error: no instruction mnemonic suffix given; can't determine immediate size". "lwpins rax, [rax],0x1" is assembled properly. objdump disassembles it as "lwpins rax,DWORD PTR [rax],0x1": $ objdump -Mintel -d asm.o asm.o: file format elf64-x86-64 Disassembly of section .text: <.text>: 0: 8f ea f8 12 00 01 00lwpins rax,DWORD PTR [rax],0x1 7: 00 00 -- 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/22831] ld causes massive thrashing if object files are not fully memory-resident: new algorithm needed
https://sourceware.org/bugzilla/show_bug.cgi?id=22831 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #23 from Nick Clifton --- (In reply to Luke Kenneth Casson Leighton from comment #22) Hi Luke, > $ python evil_linker_torture.py 3000 400 200 50 Actually this ran OK on my system. Admittedly it is a fairly big machine, and I am sure that you could suggest increased parameters that would bring it to its knees. I was a little bit confused as to why the "-g" flag appears three times in both CFLAGS and LDFLAGS. Is this really necessary ? Anyway, my main question is - have you tried using the gold linker instead of the bfd linker ? (Ie adding "-fuse-ld=gold" to the final command line). The reason being that the bfd linker is very old, and it is not wholly surprising that it does not cope well with modern, very large, binaries. The gold linker on the other hand is new, it has been designed from the ground up with large ELF programs in mind, and it does not have any of the cruft that encumbers the bfd linker. Cheers Nick PS. Waving my "devil's advocate" flag for a moment. It could be argued that not linking these gigantic binaries might actually by a good thing, as they are getting ridiculously large. Such binaries are going to take a huge amount of time (and resources) to link, and if linkers were to refuse to link them, then the programmers might have to rethink their monolithic approach and maybe come up with a more modular design. Which might not be a bad thing at all... -- 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/24074] ld fails silently when linking MinGW 64-bit app with BOINC libs
https://sourceware.org/bugzilla/show_bug.cgi?id=24074
Nick Clifton changed:
What|Removed |Added
CC||nickc at redhat dot com
--- Comment #2 from Nick Clifton ---
(In reply to Daniel from comment #0)
Hi Daniel,
> I was trying to link 64-bit MinGW app using crosscompiler on CentOS Linux.
Is the bionic library very big ? Mysterious failures like this are often
caused by the system running out of resources. Usually memory or disk space.
> GNU ld (GNU Binutils) 2.25
2.25 is an old version of the binutils. We are currently on release 2.31...
> /root/gcc-8.2.0-mingw64/lib/gcc/x86_64-w64-mingw32/8.2.0/crtend.o succeeded
> /root/gcc-8.2.0-mingw64/lib/gcc/x86_64-w64-mingw32/8.2.0/crtend.ocollect2:
> error: ld returned 1 exit status
> #2 0x00418160 in ldwrite () at ../../ld/ldwrite.c:590
Sadly that bit of code is very unhelpful:
if (!bfd_final_link (link_info.output_bfd, _info))
{
/* If there was an error recorded, print it out. Otherwise assume
an appropriate error message like unknown symbol was printed
out. */
if (bfd_get_error () != bfd_error_no_error)
einfo (_("%F%P: final link failed: %E\n"));
else
xexit (1); < this is line 590
}
So the linker is terminating, and hoping that an error message has already
been displayed. :-(
> /usr/lib/gcc/x86_64-w64-mingw32/7.4.0/../../../../x86_64-w64-mingw32/bin/ld:
> BFD (GNU Binutils) 2.29.1.20171006 assertion fail /cygdrive/i/szsz
> /tmpp/cygwin64/mingw64-x86_64/mingw64-x86_64-binutils-2.29.1.787c9873-1.x86_64
> /src/binutils-gdb/bfd/cofflink.c:265
OK, well that assertion is checking that size of ordinary symbols and
auxillary symbols is the same:
BFD_ASSERT (symesz == bfd_coff_auxesz (abfd));
Is it possible for you to find these two values ? I have a theory that
the problem is that one or maybe both of them has not been initialised.
On Linux this probably goes undetected because allocated memory is usually
zeroed, even if not explicitly requested by the program. But under mingw32
the memory could contain any random value. That is just a guess however.
Cheers
Nick
BFD_ASSERT (symesz == bfd_coff_auxesz (abfd));
--
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/24039] integer overflow in libiberty, heap overflow will be triggered
https://sourceware.org/bugzilla/show_bug.cgi?id=24039 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com Resolution|--- |MOVED --- Comment #2 from Nick Clifton --- Hi tfx, Thanks for reporting this problem. Unfortunately the cplus-dem.c source file is part of the libiberty library, which is maintained by gcc rather than the binutils. (It is used by the binutils, but not maintained by us). Please could you report this problem here: https://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc 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 binutils/24049] heap-use-after-free in readelf
https://sourceware.org/bugzilla/show_bug.cgi?id=24049 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Hi zerokeeper, Thanks for reporting this bug. I have checked in a patch to fix this particular problem and several other places where the same illegal memory access could be triggered. 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
