[Bug binutils/27261] stack overflow in cxxfilt, peek, rust-demangle.c:85

[amodra at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27261

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Alan Modra  ---
Bugs in libiberty should be reported to the owning project, which is gcc.

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

[Bug binutils/27262] stack overflow in cxxfilt, demangle_path, rust-demangle.c:674

[amodra at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27262

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Alan Modra  ---
Bugs in libiberty should be reported to the owning project, which is gcc.

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

[Bug binutils/27263] stack overflow in cxxfilt, str_buf_append, rust-demangle.c:1490

[amodra at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27263

Alan Modra  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Alan Modra  ---
Bugs in libiberty should be reported to the owning project, which is gcc.

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

[Bug binutils/27264] stack overflow in cxxfilt, demangle_type, rust-demangle.c:854

[amodra at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27264

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Alan Modra  ---
Bugs in libiberty should be reported to the owning project, which is gcc.

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

[Bug ld/27271] c6x-unknown-uclinux-ld segfaults linking ld-uClibc-1.0.37.so

[mikpelinux at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27271

--- Comment #5 from Mikael Pettersson  ---
Thanks. I can confirm that master and binutils-2_36-branch are now able to
build uClibc for c6x again.

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

[Bug ld/27259] ld: Support SHF_LINK_ORDER self-link

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27259

--- Comment #4 from cvs-commit at gcc dot gnu.org  ---
The binutils-2_36-branch branch has been updated by Alan Modra
:

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

commit fe0e833171513c1d89668bc5f454192d2db39bce
Author: Alan Modra 
Date:   Thu Jan 28 10:30:36 2021 +1030

PR27259, SHF_LINK_ORDER self-link

This stops ld from endless looping on SHF_LINK_ORDER sh_link loops.

bfd/
PR 27259
* elflink.c (_bfd_elf_gc_mark_extra_sections): Use linker_mark to
prevent endless looping of linked-to sections.
ld/
PR 27259
* ldelf.c (ldelf_before_place_orphans): Use linker_mark to
prevent endless looping of linked-to sections.

(cherry picked from commit def97fb945a98544938087eff3111e16ce58da6d)

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

[Bug ld/27259] ld: Support SHF_LINK_ORDER self-link

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27259

--- Comment #5 from cvs-commit at gcc dot gnu.org  ---
The binutils-2_35-branch branch has been updated by Alan Modra
:

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

commit 7ed5ed075b9a166f74cf13be216b3e5cf04cd622
Author: Alan Modra 
Date:   Thu Jan 28 10:30:36 2021 +1030

PR27259, SHF_LINK_ORDER self-link

This stops ld from endless looping on SHF_LINK_ORDER sh_link loops.

bfd/
PR 27259
* elflink.c (_bfd_elf_gc_mark_extra_sections): Use linker_mark to
prevent endless looping of linked-to sections.
ld/
PR 27259
* ldelf.c (ldelf_before_place_orphans): Use linker_mark to
prevent endless looping of linked-to sections.

(cherry picked from commit def97fb945a98544938087eff3111e16ce58da6d)

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

[Bug gas/27280] New: md5 DWARF v5 additions require -gdwarf-5

[ndesaulniers at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27280

Bug ID: 27280
   Summary: md5 DWARF v5 additions require -gdwarf-5
   Product: binutils
   Version: 2.35.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: gas
  Assignee: unassigned at sourceware dot org
  Reporter: ndesaulniers at google dot com
CC: hjl.tools at gmail dot com, maskray at google dot com,
nickc at redhat dot com
  Target Milestone: ---

$ echo '.file 1 "filename" md5 0x7a0b65214090b6693bd1dc24dd248245' |
binutils-gdb/gas/as -
{standard input}: Assembler messages:
{standard input}:1: Error: junk at end of line, first unrecognized character is
`m'
$ echo '.file 1 "filename" md5 0x7a0b65214090b6693bd1dc24dd248245' |
binutils-gdb/gas/as -gdwarf-5 -

Support for these md5 hashes was addressed in
https://sourceware.org/bugzilla/show_bug.cgi?id=25611, but they still require
-gdwarf-5.

-gdwarf-5 is not required for `.file 0` in
https://sourceware.org/bugzilla/show_bug.cgi?id=27195.  The same approach
should be used to avoid requiring `-gdwarf-5` to be passed explicitly, since
the compiler (clang -no-integrated-as) will produce these checksums when
`-gdwarf-5` is used and the compiler is used as the driver.

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

ar: wrong permissions on output file with binutils 2.36

[Adam Sampson]

Hi binutils maintainers,

I've just run into an interesting problem when building plan9port with
binutils 2.36: it uses "ar rcs" to build static libraries, but one of
the libraries -- lib9.a, which has a very long list of objects -- ends
up with permission 0600 rather than the intended 0644.

Here's a script that reproduces the problem for me on amd64 GNU/Linux
with GCC 10.2.0:

-
#!/bin/sh

echo "int x;" >t.c
gcc -c t.c
for i in $(seq 100 299); do
cp t.o $i.o
done

rm -f libt.a
ar rcs libt.a 1*.o
ls -l libt.a

rm -f libt.a
ar rcs libt.a [12]*.o
ls -l libt.a
-

This produces the output:

-rw-r--r-- 1 root root 101072 Jan 29 22:23 libt.a
-rw--- 1 root root 202072 Jan 29 22:23 libt.a

Tracing through the ar code, this seems to be fallout from this change:
https://lists.gnu.org/archive/html/bug-binutils/2021-01/msg00089.html

In write_archive, with the shorter argument list, iarch->iostream is
non-NULL; with the longer list, iarch->iostream is NULL, and skip_stat
is set to TRUE, so the permissions don't get set.

It looks from the libbfd code like ->iostream can legitimately be NULL
while the file is open, so I think the new test in write_archive is
incorrect.

Thanks very much,

-- 
Adam Sampson  

[Bug gas/27280] md5 DWARF v5 additions require -gdwarf-5

[maskray at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27280

--- Comment #1 from Fangrui Song  ---
The idea of .file 0 auto-upgrade is that the compiler should emit .file 0
before .file 1, so the assembler does not need to deal with DWARF v5 md5
syntax.

I compiled a top-of-tree GCC. It emits `.file 1` instead of `.file 0`. So what
is current GCC's support for version 5 .debug_line? You can see that `clang
-gdwarf-5 -S` emits `.file 0`.

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

[Bug gas/27280] md5 DWARF v5 additions require -gdwarf-5

[ndesaulniers at google dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27280

Nick Desaulniers  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Nick Desaulniers  ---
> the compiler should emit .file 0 before .file 1

Got it.  Looks like I can feature detect not needing -gdwarf-5 for gas then
via:

$ echo '.file 0 "filename"\n.file 1 "filename" md5
0x7a0b65214090b6693bd1dc24dd248245'  | binutils-gdb/gas/as -

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

[Bug binutils/27281] New: readelf: SHF_GNU_RETAIN ('R') is not listed in `Key to Flags:`

[i at maskray dot me]

https://sourceware.org/bugzilla/show_bug.cgi?id=27281

Bug ID: 27281
   Summary: readelf: SHF_GNU_RETAIN ('R') is not listed in `Key to
Flags:`
   Product: binutils
   Version: unspecified
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: i at maskray dot me
  Target Milestone: ---

Example readelf -WS output:

Section Headers:
  [Nr] Name  TypeAddress  OffSize   ES Flg
Lk Inf Al
...
  [ 4] .orphaned_section PROGBITS 40 02 00 AXR 
0   0  1
...
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  l (large), p (processor specific)

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

[Bug ld/27282] New: ld: Should SHF_GNU_RETAIN/STT_GNU_IFUNC/STB_GNU_UNIQUE work for ELFOSABI_NONE object files?

[i at maskray dot me]

https://sourceware.org/bugzilla/show_bug.cgi?id=27282

Bug ID: 27282
   Summary: ld: Should SHF_GNU_RETAIN/STT_GNU_IFUNC/STB_GNU_UNIQUE
work for ELFOSABI_NONE object files?
   Product: binutils
   Version: unspecified
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: i at maskray dot me
  Target Milestone: ---

ld -m elf_x86_64  recognizes semantics of OS-specific
STT_GNU_IFUNC/STB_GNU_UNIQUE in ELFOSABI_NONE object files.

  LLVM integrated assembler as of 12.0.0 does not set ELFOSABI_GNU if you use
@gnu_indirect_function/@gnu_unique_object.

  Question: how do GNU as set OSABI for STT_GNU_IFUNC/STB_GNU_UNIQUE on
FreeBSD? Is the behavior host platform dependent? 

However, ld -m elf_x86_64  does not recognize SHF_GNU_RETAIN in ELFOSABI_NONE
object files.

So these section/symbol properties have some inconsistency.
I can see two choices.


1. (Current behavior)
Ignore semantics of SHF_GNU_RETAIN in ELFOSABI_NONE object files.
If we want to make rules consistent, we should do this for
STT_GNU_IFUNC/STB_GNU_UNIQUE,
but it would break all the object files produced by LLVM integrated assembler.

2.
Recognize the semantics of SHF_GNU_RETAIN if the ld configuration & options
indicate Linux target (e.g. ld -m elf_x86_64 on Linux),
regardless of EI_OSABI in object files.
This choice gives discretion to the linker.

I think the only downside is that readelf -S does not display 'R' for
SHF_GNU_RETAIN,
like readelf -s doesn't show IFUNC for LLVM integrated assembler assembled
object files today.

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