[Bug ld/32643] ld SEGV (illegal read access) in _bfd_elf_gc_mark_rsec (bfd/elflink.c:14031:11) with --gc-sections --no-print-gc-sections -w options
https://sourceware.org/bugzilla/show_bug.cgi?id=32643 Michael Matz changed: What|Removed |Added CC||matz at suse dot de --- Comment #3 from Michael Matz --- (In reply to Nick Clifton from comment #2) > With this patch I have tried to cover other cases where similar assumptions > are made, so maybe the patch will fix more than just this one PR. While hardening the code is perhaps a reasonable idea (if not too expensive), isn't the actual problem rather that -w disabled exit-on-error (an error message is clearly given here), like Alan fixed in https://sourceware.org/bugzilla/show_bug.cgi?id=32603 ? I.e. why are we even running the GC section code when an input file is invalid? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32644] ld SEGV (illegal read access) in bfd_elf_reloc_symbol_deleted_p (bfd/elflink.c:15103:19) --no-undefined --orphan-handling discard -w -r -d options
https://sourceware.org/bugzilla/show_bug.cgi?id=32644 Michael Matz changed: What|Removed |Added CC||matz at suse dot de --- Comment #3 from Michael Matz --- (In reply to Nick Clifton from comment #2) > Fixed. > > A case I had not considered in the previous patches, but simple enough to > fix. Similar to PR32643, shouldn't the error message that's clearly there have prevented the followup code from running, even in presence of -w? I.e. like fixed in PR32603? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/32644] ld SEGV (illegal read access) in bfd_elf_reloc_symbol_deleted_p (bfd/elflink.c:15103:19) --no-undefined --orphan-handling discard -w -r -d options
https://sourceware.org/bugzilla/show_bug.cgi?id=32644 --- Comment #4 from Nick Clifton --- (In reply to Michael Matz from comment #3) > Similar to PR32643, shouldn't the error message that's clearly there have > prevented the followup code from running, even in presence of -w? I.e. > like fixed in PR32603? Agreed, that would be the better way to fix this issue. My default thinking however is that all code should be robust, even if it never expects to have to handle bad input. Just relying on earlier code to filter out the bad stuff is never reliable. At least in my opinion. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31101] [2.42 Regression] nopic link exec test fails on loongarch64-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=31101 Lulu Cai changed: What|Removed |Added CC||cailulu at loongson dot cn --- Comment #1 from Lulu Cai --- Certain distributions, like Debian, insert the `--as-needed` early in the linking command sequence. This can prevent essential libraries required by test cases from being linked, leading to potential failures. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/32382] beq is misassembled
https://sourceware.org/bugzilla/show_bug.cgi?id=32382 --- Comment #3 from Jackson Huff --- I'm now testing the same with .insn b 0b1001011, 0b111, a2, a3, 64 and the standards-compliant hex output should be 4b 70 d6 04, but as generated 4b 64 d6 00 6f 00 00 00. -- You are receiving this mail because: You are on the CC list for the bug.
Issue 395921930: binutils:fuzz_disassemble: Direct-leak in xcalloc
Replying to this email means your email address will be shared with the team that works on this product. https://issues.oss-fuzz.com/issues/395921930 Reference Info: 395921930 binutils:fuzz_disassemble: Direct-leak in xcalloc component: Public Trackers > 1362134 > OSS Fuzz status: New reporter: 87...@developer.gserviceaccount.com cc: am...@gmail.com, bug-binutils@gnu.org, da...@adalogics.com, and 2 more collaborators: co...@oss-fuzz.com type: Bug access level: Limited visibility priority: P2 severity: S4 hotlist: Reproducible, Stability-Memory-AddressSanitizer, Stability-Memory-LeakSanitizer retention: Component default Project: binutils Reported: Feb 12, 2025 87...@developer.gserviceaccount.com added comment #1: Detailed Report: https://oss-fuzz.com/testcase?key=4551310221574144 Project: binutils Fuzzing Engine: libFuzzer Fuzz Target: fuzz_disassemble Job Type: libfuzzer_asan_binutils Platform Id: linux Crash Type: Direct-leak Crash Address: Crash State: xcalloc print_insn_riscv fuzz_disassemble.c Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_binutils&range=202502110611:202502120638 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4551310221574144 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. This bug is subject to a 90 day disclosure deadline. If 90 days elapse without an upstream patch, then the bug report will automatically become visible to the public. Generated by Google IssueTracker notification system. You're receiving this email because you are subscribed to updates on Google IssueTracker issue 395921930 Unsubscribe from this issue.
[Bug ld/32666] Incorrect .rela.sframe when using ld -r
https://sourceware.org/bugzilla/show_bug.cgi?id=32666 --- Comment #2 from Indu Bhagat --- Confirmed. In presence of bad offsets, relocating SFrame sections with bad .rela.sframe will result in bad data in the SFrame section. The issue is that with relocatable link, we need to manually adjust (in GNU ld) the section offsets as GNU ld merges the input sections. The issue is not present in normal links of SFrame sections. -- You are receiving this mail because: You are on the CC list for the bug.
