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

https://sourceware.org/bugzilla/show_bug.cgi?id=27261 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

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

https://sourceware.org/bugzilla/show_bug.cgi?id=27262 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

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

https://sourceware.org/bugzilla/show_bug.cgi?id=27263 Alan Modra changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED

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

https://sourceware.org/bugzilla/show_bug.cgi?id=27264 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

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

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

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 fe0e833171513c1

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

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 7ed5ed075b9a166

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

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:

ar: wrong permissions on output file with binutils 2.36

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'

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

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` i

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

https://sourceware.org/bugzilla/show_bug.cgi?id=27280 Nick Desaulniers changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFI

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

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: no

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

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: UNCON