[Bug gprofng/30093] gprofng SIGSEGV when processing unusual dwarf

2023-02-08 Thread cvs-commit at gcc dot gnu.org
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

2023-02-08 Thread sheriffbot via monorail
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

2023-02-08 Thread sheriffbot via monorail
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

2023-02-08 Thread murphyp at linux dot vnet.ibm.com
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

2023-02-08 Thread cvs-commit at gcc dot gnu.org
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

2023-02-08 Thread sam at gentoo dot org
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

2023-02-08 Thread sam at gentoo dot org
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

2023-02-08 Thread sam at gentoo dot org
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

2023-02-08 Thread sam at gentoo dot org
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

2023-02-08 Thread sam at gentoo dot org
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

2023-02-08 Thread sam at gentoo dot org
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)

2023-02-08 Thread sam at gentoo dot org
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)

2023-02-08 Thread sam at gentoo dot org
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

2023-02-08 Thread nelsonc1225 at sourceware dot org
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

2023-02-08 Thread nelsonc1225 at sourceware dot org
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

2023-02-08 Thread nelsonc1225 at sourceware dot org
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.