[Bug binutils/30551] [RISCV] Improper endian encoding when using floats and doubles with -mbig-endian
https://sourceware.org/bugzilla/show_bug.cgi?id=30551 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Andreas Schwab : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=71a75b51a62b5cbc12c68b9c4d1dcae0f8a59263 commit 71a75b51a62b5cbc12c68b9c4d1dcae0f8a59263 Author: Andreas Schwab Date: Tue Jun 13 14:49:38 2023 +0200 riscv: Use run-time endianess for floating point literals gas/ PR binutils/30551 * config/tc-riscv.c (md_atof): Use target_big_endian instead of TARGET_BYTES_BIG_ENDIAN. * testsuite/gas/riscv/float-be.d: New file. * testsuite/gas/riscv/float-le.d: New file. * testsuite/gas/riscv/float.s: New file. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30560] Heap-buffer-overflow (SEGV) in elf_x86_64_relocate_section()
https://sourceware.org/bugzilla/show_bug.cgi?id=30560 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com Last reconfirmed||2023-06-19 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at sourceware dot org |nickc at redhat dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30560] Heap-buffer-overflow (SEGV) in elf_x86_64_relocate_section()
https://sourceware.org/bugzilla/show_bug.cgi?id=30560 --- 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=74d39f70cd9090ba1cdc406421480bb50a864cd2 commit 74d39f70cd9090ba1cdc406421480bb50a864cd2 Author: Nick Clifton Date: Mon Jun 19 12:09:11 2023 +0100 Fix illegal memory access implementing relocs in a fuzzed x86_64 object file. PR 30560 * elf64-x86-64.c (elf_x86_64_relocate_section): Add more checks for a valid relocation offset. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30560] Heap-buffer-overflow (SEGV) in elf_x86_64_relocate_section()
https://sourceware.org/bugzilla/show_bug.cgi?id=30560 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Nick Clifton --- Patch applied. It turns out that there were some more places in the code where we need to check for invalid relocation offsets. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30561] conversion from binary to PE broken
https://sourceware.org/bugzilla/show_bug.cgi?id=30561 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Stas, To be honest I am not at all surprised by this. Converting arbitrary binary input into a specific file format is never going to work well. There is just not enough information in the input format to enable a proper conversion. Instead may I suggest an alternative, using the assembler's .incbin directive, like this: $ cat tst.s .data .incbin "/etc/resolv.conf" $ as tst.s -o tst.o $ file tst.o tst.o: Intel amd64 COFF object file, no relocation info, no line number info, not stripped, 3 sections, symbol offset=0x43c, 8 symbols, 1st section name ".text" $ objdump -P header tst.o tst.o: file format pe-x86-64 File header not present Image Header (at offset 0): Machine Number: 0x8664 - AMD64 Number of sections: 3 Time/Date:- not set Symbol table offset: 0x00043c Number of symbols:8 Optional header size: 0 Flags:0x0005 - RELOCS STRIPPED,LINE NUMS STRIPPED Optional header not present Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30561] conversion from binary to PE broken
https://sourceware.org/bugzilla/show_bug.cgi?id=30561 --- Comment #2 from Stas Sergeev --- Hi Nick, thanks for a suggestion. Its not as simple, at the very minimum I'll need to generate with some script such .S files, so that they provide the needed symbols, like _binary__etc_resolv_conf_start _binary__etc_resolv_conf_end _binary__etc_resolv_conf_size. I know how to do that. Still would you mind clarifying why "There is just not enough information in the input format to enable a proper conversion"? If this is true, then I'll just write the script. If not true - I would expect the bugfix is needed. :) Please note that converting the same to ELF works well. In this particular case it seems likely the PE header got messed up. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30566] New: -z pack-relative-relocs --no-keep-memory uses more memory than without --no-keep-memory
https://sourceware.org/bugzilla/show_bug.cgi?id=30566 Bug ID: 30566 Summary: -z pack-relative-relocs --no-keep-memory uses more memory than without --no-keep-memory Product: binutils Version: 2.40 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: mh-sourceware at glandium dot org Target Milestone: --- When linking libxul.so from Firefox, with -z pack-relative-relocs (output from time -v): Maximum resident set size (kbytes): 13170360 When adding --no-keep-memory: Maximum resident set size (kbytes): 72244188 ... and that's not actually the entire story because the process is OOM-killed before actually finishing. STR: - download and extract https://drive.google.com/file/d/15UZd8u9j_nZdjhlqdHkswyaUf08gmRAP/view?usp=sharing - in the repr/ directory, run ld @response.txt --no-keep-memory -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30566] -z pack-relative-relocs --no-keep-memory uses more memory than without --no-keep-memory
https://sourceware.org/bugzilla/show_bug.cgi?id=30566 Mike Hommey changed: What|Removed |Added CC||hjl.tools at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
