[Bug ld/24678] RISC-V pcrel relocs and abs global pointer variable
https://sourceware.org/bugzilla/show_bug.cgi?id=24678 Andrew Pinski changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=24983 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/24983] RISC-V GP linker relaxation is not performed with -nostdlib
https://sourceware.org/bugzilla/show_bug.cgi?id=24983 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org See Also||https://github.com/riscv-co ||llab/riscv-gnu-toolchain/is ||sues/497, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=91713, ||https://sourceware.org/bugz ||illa/show_bug.cgi?id=24678 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/24983] RISC-V GP linker relaxation is not performed with -nostdlib
https://sourceware.org/bugzilla/show_bug.cgi?id=24983 Andrew Pinski changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=29509 -- 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 Andrew Pinski changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=29509 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29509] The RISCV linker relaxation is just plain broken and should be removed
https://sourceware.org/bugzilla/show_bug.cgi?id=29509 Andrew Pinski changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=28441, ||https://sourceware.org/bugz ||illa/show_bug.cgi?id=24983, ||https://sourceware.org/bugz ||illa/show_bug.cgi?id=28878 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28878] [RISCV] Incorrect DW_AT_high_pc for assembly source with linker relaxation
https://sourceware.org/bugzilla/show_bug.cgi?id=28878 Andrew Pinski changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=29509 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29509] New: The RISCV linker relaxation is just plain broken and should be removed
https://sourceware.org/bugzilla/show_bug.cgi?id=29509 Bug ID: 29509 Summary: The RISCV linker relaxation is just plain broken and should be removed Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: riscv Deleting data while doing relaxation is not only slow (see PR 28441) but forces many real bugs (see PR 24983 and PR 28878 and others). Therefore it should be removed and GCC should do many of them. -- You are receiving this mail because: You are on the CC list for the bug.
Issue 50412 in oss-fuzz: binutils:fuzz_objcopy: Use-of-uninitialized-value in cache_bwrite
Updates: Labels: -restrict-view-commit Comment #3 on issue 50412 by sheriffbot: binutils:fuzz_objcopy: Use-of-uninitialized-value in cache_bwrite https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=50412#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[Bug binutils/29505] xxx-w64-mingw32-objdump takes a long time to scan pe binaries for debug information
https://sourceware.org/bugzilla/show_bug.cgi?id=29505 --- Comment #1 from Ralf Habacker --- (In reply to Ralf Habacker from comment #0) > The question is whether objdump itself or in conjunction with the binaries > used can cause this problem and if so, how to fix it. At least objdump seems to have memory leaks $ valgrind --leak-check=full i686-w64-mingw32-objdump -Wi bin/assistant.exe > /dev/null ==30665== Memcheck, a memory error detector ==30665== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==30665== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info ==30665== Command: i686-w64-mingw32-objdump -Wi bin/assistant.exe ==30665== ==30665== ==30665== HEAP SUMMARY: ==30665== in use at exit: 745,472 bytes in 73 blocks ==30665== total heap usage: 739,195 allocs, 739,122 frees, 125,826,656,614 bytes allocated ==30665== ==30665== 221,184 bytes in 9 blocks are definitely lost in loss record 1 of 2 ==30665==at 0x4C338CF: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==30665==by 0x24F99C: xrealloc (xmalloc.c:181) ==30665==by 0x1722E8: UnknownInlinedFun (dwarf.c:10762) ==30665==by 0x1722E8: read_and_display_attr_value (dwarf.c:2792) ==30665==by 0x173DBF: UnknownInlinedFun (dwarf.c:3342) ==30665==by 0x173DBF: process_debug_info (dwarf.c:3956) ==30665==by 0x182A34: load_separate_debug_files (dwarf.c:11542) ==30665==by 0x1619A6: dump_bfd (objdump.c:5028) ==30665==by 0x1621EC: display_object_bfd (objdump.c:5221) ==30665==by 0x1621EC: display_any_bfd (objdump.c:5311) ==30665==by 0x1622B3: display_file (objdump.c:5332) ==30665==by 0x15C58C: main (objdump.c:5700) ==30665== ==30665== 524,288 bytes in 64 blocks are definitely lost in loss record 2 of 2 ==30665==at 0x4C312EF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==30665==by 0x24F9AF: xrealloc (xmalloc.c:179) ==30665==by 0x1722E8: UnknownInlinedFun (dwarf.c:10762) ==30665==by 0x1722E8: read_and_display_attr_value (dwarf.c:2792) ==30665==by 0x173DBF: UnknownInlinedFun (dwarf.c:3342) ==30665==by 0x173DBF: process_debug_info (dwarf.c:3956) ==30665==by 0x182A34: load_separate_debug_files (dwarf.c:11542) ==30665==by 0x1619A6: dump_bfd (objdump.c:5028) ==30665==by 0x1621EC: display_object_bfd (objdump.c:5221) ==30665==by 0x1621EC: display_any_bfd (objdump.c:5311) ==30665==by 0x1622B3: display_file (objdump.c:5332) ==30665==by 0x15C58C: main (objdump.c:5700) ==30665== ==30665== LEAK SUMMARY: ==30665==definitely lost: 745,472 bytes in 73 blocks ==30665==indirectly lost: 0 bytes in 0 blocks ==30665== possibly lost: 0 bytes in 0 blocks ==30665==still reachable: 0 bytes in 0 blocks ==30665== suppressed: 0 bytes in 0 blocks ==30665== ==30665== For lists of detected and suppressed errors, rerun with: -s ==30665== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) -- You are receiving this mail because: You are on the CC list for the bug.
