[Bug gprofng/30093] gprofng SIGSEGV when processing unusual dwarf
https://sourceware.org/bugzilla/show_bug.cgi?id=30093 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Vladimir Mezentsev : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e02841b095a7797aaae1b064fb4b7acc2eb8d900 commit e02841b095a7797aaae1b064fb4b7acc2eb8d900 Author: Vladimir Mezentsev Date: Tue Feb 7 14:58:25 2023 -0800 gprofng: fix SIGSEGV when processing unusual dwarf gprofng/ChangeLog 2023-02-07 Vladimir Mezentsev PR gprofng/30093 * src/Dwarf.cc: add nullptr check. * src/DwarfLib.cc: Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
Issue 53472 in oss-fuzz: binutils:fuzz_nm: Out-of-memory in fuzz_nm
Updates: Labels: Deadline-Approaching Comment #3 on issue 53472 by sheriffbot: binutils:fuzz_nm: Out-of-memory in fuzz_nm https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=53472#c3 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - 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.
Issue 54397 in oss-fuzz: binutils:fuzz_addr2line: Heap-use-after-free in bfd_getl16
Updates: Labels: -restrict-view-commit Comment #3 on issue 54397 by sheriffbot: binutils:fuzz_addr2line: Heap-use-after-free in bfd_getl16 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=54397#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 gas/30046] power cmpi leads to unknown architecture
https://sourceware.org/bugzilla/show_bug.cgi?id=30046 Paul E. Murphy changed: What|Removed |Added CC||murphyp at linux dot vnet.ibm.com --- Comment #2 from Paul E. Murphy --- pwr and pwr2 machine options select bfd_arch_rs6000 machine. The elf backend bits for ppc seem to assume a bfd_arch_powerpc machine. The mismatch is visible when _bfd_elf_set_arch_mach is called, fails, and the failure is quietly ignored when setting up the output object file. I suspect there is more history between the powerpc and rs6000 backends that I don't understand yet. Should the assembler generate an error instead of trying to generate an elf object for very, very old power cpus? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/24707] binutils crash invoke files, by using afl fuzzing
https://sourceware.org/bugzilla/show_bug.cgi?id=24707 --- Comment #4 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=87d206578e152d81d903a0beec8bd3927154eb30 commit 87d206578e152d81d903a0beec8bd3927154eb30 Author: Alan Modra Date: Wed Feb 8 14:41:58 2023 +1030 Clear cached file size when bfd changed to BFD_IN_MEMORY If file size is calculated by bfd_get_file_size, as it is by _bfd_alloc_and_read calls in coff_object_p, then it is cached and when pe_ILF_build_a_bfd converts an archive entry over to BFD_IN_MEMORY, the file size is no longer valid. Found when attempting objdump -t on a very small (27 bytes) ILF file and hitting the pr24707 fix (commit 781152ec18f5). So, clear file size when setting BFD_IN_MEMORY on bfds that may have been read. (It's not necessary in writable bfds, because caching is ignored by bfd_get_size when bfd_write_p.) I also think the PR 24707 fix is no longer neeeded. All of the testcases in that PR and in PR24712 are caught earlier by file size checks when reading the symbols from file. So I'm reverting that fix, which just compared the size of an array of symbol pointers against file size. That's only valid if on-disk symbols are larger than a host pointer, so the test is better done in format-specific code. bfd/ * coff-alpha.c (alpha_ecoff_get_elt_at_filepos): Clear cached file size when making a BFD_IN_MEMORY bfd. * opncls.c (bfd_make_readable): Likewise. * peicode.h (pe_ILF_build_a_bfd): Likewise. binutils/ PR 24707 * objdump.c (slurp_symtab): Revert PR24707 fix. Tidy. (slurp_dynamic_symtab): Tidy. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27305] relinking libctf during install does not find libbfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27305 Sam James changed: What|Removed |Added CC||sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29042] opcodes libtool regression
https://sourceware.org/bugzilla/show_bug.cgi?id=29042 Sam James changed: What|Removed |Added CC||sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/28545] cross compile incorrectly using host libraries in install relink
https://sourceware.org/bugzilla/show_bug.cgi?id=28545 Sam James changed: What|Removed |Added CC||sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29042] opcodes libtool regression
https://sourceware.org/bugzilla/show_bug.cgi?id=29042 Sam James changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=27360 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 Sam James changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=29042 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29042] opcodes libtool regression
https://sourceware.org/bugzilla/show_bug.cgi?id=29042 --- Comment #5 from Sam James --- I suspect this is the same as an issue we've been hitting in Gentoo (https://bugs.gentoo.org/834720) which is mostly noticeable if built the previous system copy of binutils with --enable-pgo=lto (or otherwise built binutils with LTO) with an older GCC, then rebuilding with a newer different version of GCC which marks itself as having a different bitcode version. Manifests as (remains for newer versions): ``` lto1: fatal error: bytecode stream in file '/usr/lib64/binutils/x86_64-pc-linux-gnu/2.37_p1/libiberty.a' generated with LTO version 11.0 instead of the expected 11.2 compilation terminated. lto-wrapper: fatal error: x86_64-pc-linux-gnu-gcc returned 1 exit status compilation terminated. ``` I ended up hitting the same issue, just manifesting differently recently, when GCC's bitcode changed for 13. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29042] opcodes libtool regression (relinks libopcodes during install, picks up wrong libiberty from system)
https://sourceware.org/bugzilla/show_bug.cgi?id=29042 Sam James changed: What|Removed |Added Summary|opcodes libtool regression |opcodes libtool regression ||(relinks libopcodes during ||install, picks up wrong ||libiberty from system) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29042] [2.38 regression] opcodes libtool regression (relinks libopcodes during install, picks up wrong libiberty from system)
https://sourceware.org/bugzilla/show_bug.cgi?id=29042 Sam James changed: What|Removed |Added Summary|opcodes libtool regression |[2.38 regression] opcodes |(relinks libopcodes during |libtool regression (relinks |install, picks up wrong |libopcodes during install, |libiberty from system) |picks up wrong libiberty ||from system) CC||toolchain at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30099] New: objdump riscv: stop disassembling addi rd, rs, 0 with a relocation as mv rd, rs
https://sourceware.org/bugzilla/show_bug.cgi?id=30099 Bug ID: 30099 Summary: objdump riscv: stop disassembling addi rd, rs, 0 with a relocation as mv rd, rs Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: nelsonc1225 at sourceware dot org Target Milestone: --- Copy from here, https://inbox.sourceware.org/binutils/ds7pr12mb57659139c1d9ea568403722dcb...@ds7pr12mb5765.namprd12.prod.outlook.com/ In llvm-project, https://reviews.llvm.org/D143345 brings up the topic whether we should keep addi rd, rs, 0 when it is associated with a relocation. If it does, the relocation may resolve to a non-zero and `mv rd, rs` may look confusing. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30099] objdump riscv: stop disassembling addi rd, rs, 0 with a relocation as mv rd, rs
https://sourceware.org/bugzilla/show_bug.cgi?id=30099 --- Comment #1 from Nelson Chu --- Created attachment 14662 --> https://sourceware.org/bugzilla/attachment.cgi?id=14662&action=edit proposed solution v1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30099] objdump riscv: stop disassembling addi rd, rs, 0 with a relocation as mv rd, rs
https://sourceware.org/bugzilla/show_bug.cgi?id=30099 --- Comment #2 from Nelson Chu --- Some minor issues for implementation, * I like the idea from Maciej to define a new instruction type, INSN_NORELOC, in the opcode table. But seems like we didn't left enough encodings for INSN_TYPE, so the values of new types cannot be continuous with other old types. I just randomly choose 0x2000 temporarily, maybe we should redefine them to preserve enough encodings for future extend? or just extend them from 0x2000 down? * Not sure if it causes problems when we enable info->disassembler_needs_relocs in the disassemble_init_for_target. The INSN_HAS_RELOC needs info->disassembler_needs_relocs be enabled. But I only see arc enable it for now, so not sure what the consequences are. Otherwise, applying the proposed patch, I can get the expected result, % cat tmp.s foo: addia0, a1, %lo(foo) addia0, a1, 10 addia0, a1, 0 mv a0, a1 % riscv64-unknown-elf-as tmp.s -o tmp.o % riscv64-unknown-elf-objdump -d tmp.o tmp.o: file format elf64-littleriscv Disassembly of section .text: : 0: 00058513add a0,a1,0 4: 00a58513add a0,a1,10 8: 00058513mv a0,a1 c: 00058513mv a0,a1 % riscv64-unknown-elf-objdump -d -Mno-aliases tmp.o tmp.o: file format elf64-littleriscv Disassembly of section .text: : 0: 00058513addia0,a1,0 4: 00a58513addia0,a1,10 8: 00058513addia0,a1,0 c: 00058513addia0,a1,0 -- You are receiving this mail because: You are on the CC list for the bug.