[Bug binutils/29397] New: binutils: support zstd
https://sourceware.org/bugzilla/show_bug.cgi?id=29397
Bug ID: 29397
Summary: binutils: support zstd
Product: binutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
Zstandard is a "universal" compression algorithm which scales from
low-ratio-very-fast to high-ratio-pretty-slow.
The generic-abi proposal https://groups.google.com/g/generic-abi/c/satyPkuMisk
("Add new ch_type value: ELFCOMPRESS_ZSTD") has been approved.
The default zstd -3 is easily 7x as fast as zlib level 1 while having a higher
compression ratio.
See also https://sourceware.org/pipermail/gnu-gabi/2022q2/000498.html
binutils may need to:
* optional: import zstd/ as a toplevel directory like zlib/
* add configure.ac option --with-system-zstd
* gas: add --compress-debug-sections=zstd
* objcopy: add --compress-debug-sections=zstd
* ld: support ELFCOMPRESS_ZSTD input, add --compress-debug-sections=zstd
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/29397] binutils: support zstd
https://sourceware.org/bugzilla/show_bug.cgi?id=29397 Fangrui Song changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||nick.alcock at oracle dot com, ||nickc at redhat dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29397] binutils: support zstd
https://sourceware.org/bugzilla/show_bug.cgi?id=29397 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/29397] binutils: support zstd for SHF_COMPRESSED debug sections
https://sourceware.org/bugzilla/show_bug.cgi?id=29397 Fangrui Song changed: What|Removed |Added Summary|binutils: support zstd |binutils: support zstd for ||SHF_COMPRESSED debug ||sections -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29401] New: Hang when compiling large printf() file (from glibc's tst-printf-bz18872) on HPPA with -ggdb3
https://sourceware.org/bugzilla/show_bug.cgi?id=29401 Bug ID: 29401 Summary: Hang when compiling large printf() file (from glibc's tst-printf-bz18872) on HPPA with -ggdb3 Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: sam at gentoo dot org Target Milestone: --- Created attachment 14228 --> https://sourceware.org/bugzilla/attachment.cgi?id=14228&action=edit tst-printf-bz18872.c Dumped my initial thoughts at https://bugs.gentoo.org/860819 when found this. The hang only occurs on a native compiler so far (not cross). Happy to give access to a machine used for Gentoo testing to aid debugging. Requires -ggdb3 at least, possibly other debugging levels too. Compiles quickly without -ggdb3 (e.g. hppa2.0-unknown-linux-gnu-gcc -pipe -march=2.0 -fdiagnostics-show-option -O2 -Wl,-O1 -Wl,--as-needed foo.c). Noticed when building glibc's test suite on hppa2.0-unknown-linux-gnu and compilation hanged on: ``` hppa2.0-unknown-linux-gnu-gcc -pipe -march=2.0 -fdiagnostics-show-option -ggdb3 -O2 -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu /var/tmp/portage/sys-libs/glibc-/work/build-hppa-hppa2.0-unknown-linux-gnu-nptl/stdio-common/tst-printf-bz18872.c -c -std=gnu11 -fgnu89-inline -pipe -march=2.0 -fdiagnostics-show-option -ggdb3 -O2 -Wall -Wwrite-strings -Wundef -fmerge-all-constants -frounding-math -fno-stack-protector -fno-common -Wstrict-prototypes -Wold-style-definition -fmath-errno-fno-pie -U_FORTIFY_SOURCE -I../include -I/var/tmp/portage/sys-libs/glibc-/work/build-hppa-hppa2.0-unknown-linux-gnu-nptl/stdio-common -I/var/tmp/portage/sys-libs/glibc-/work/build-hppa-hppa2.0-unknown-linux-gnu-nptl -I../sysdeps/unix/sysv/linux/hppa -I../sysdeps/hppa/nptl -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread -I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/hppa/hppa1.1 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/hppa/fpu -I../sysdeps/hppa -I../sysdeps/ieee754 -I../sysdeps/generic -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/hppa2.0-unknown-linux-gnu/11.3.0/include -isystem /usr/lib/gcc/hppa2.0-unknown-linux-gnu/11.3.0/include-fixed -isystem /usr/include -D_LIBC_REENTRANT -include /var/tmp/portage/sys-libs/glibc-/work/build-hppa-hppa2.0-unknown-linux-gnu-nptl/libc-modules.h -DMODULE_NAME=testsuite -include ../include/libc-symbols.h -DPIC -DTOP_NAMESPACE=glibc -D_IO_MTSAFE_IO -o /var/tmp/portage/sys-libs/glibc-/work/build-hppa-hppa2.0-unknown-linux-gnu-nptl/stdio-common/tst-printf-bz18872.o -MD -MP -MF /var/tmp/portage/sys-libs/glibc-/work/build-hppa-hppa2.0-unknown-linux-gnu-nptl/stdio-common/tst-printf-bz18872.o.dt -MT /var/tmp/portage/sys-libs/glibc-/work/build-hppa-hppa2.0-unknown-linux-gnu-nptl/stdio-common/tst-printf-bz18872.o ``` As far as I can tell, GCC invokes `as` and then it hangs indefinitely. I can reproduce this outside of glibc's test suite with the attached file: ``` $ hppa2.0-unknown-linux-gnu-gcc -pipe -march=2.0 -g -O2 -Wl,-O1 -Wl,--as-needed foo.c -v Using built-in specs. COLLECT_GCC=hppa2.0-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/hppa2.0-unknown-linux-gnu/11.2.1/lto-wrapper Target: hppa2.0-unknown-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/configure --host=hppa2.0-unknown-linux-gnu --build=hppa2.0-unknown-linux-gnu --prefix=/usr --bindir=/usr/hppa2.0-unknown-linux-gnu/gcc-bin/11.2.1 --includedir=/usr/lib/gcc/hppa2.0-unknown-linux-gnu/11.2.1/include --datadir=/usr/share/gcc-data/hppa2.0-unknown-linux-gnu/11.2.1 --mandir=/usr/share/gcc-data/hppa2.0-unknown-linux-gnu/11.2.1/man --infodir=/usr/share/gcc-data/hppa2.0-unknown-linux-gnu/11.2.1/info --with-gxx-include-dir=/usr/lib/gcc/hppa2.0-unknown-linux-gnu/11.2.1/include/g++-v11 --with-python-dir=/share/gcc-data/hppa2.0-unknown-linux-gnu/11.2.1/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 11.2.1_p20220115 p4' --disable-esp --enable-libstdcxx-time --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-fixed-point --enable-libgomp --disable-libssp --disable-libada --disable-cet --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --without-zstd --enable-lto --without-isl --disable-libsanitizer --enable-default-pie --disable-default-ssp Thread model: posix Supported LTO compression
[Bug gas/29401] Hang when compiling large printf() file (from glibc's tst-printf-bz18872) on HPPA with -ggdb3
https://sourceware.org/bugzilla/show_bug.cgi?id=29401 Sam James changed: What|Removed |Added Host||hppa2.0-unknown-linux-gnu URL||https://bugs.gentoo.org/860 ||819 Target||hppa2.0-unknown-linux-gnu Build||hppa2.0-unknown-linux-gnu -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29401] Hang when compiling large printf() file (from glibc's tst-printf-bz18872) on HPPA with -ggdb3
https://sourceware.org/bugzilla/show_bug.cgi?id=29401 Sam James changed: What|Removed |Added CC||danglin at gcc dot gnu.org, ||deller at gmx dot de --- Comment #1 from Sam James --- Versions: - gcc (Gentoo 11.2.1_p20220115 p4) 11.2.1 20220115 - GNU ld (Gentoo 2.37_p1 p2) 2.37 - kernel 5.19.0-rc4 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29401] Hang when compiling large printf() file (from glibc's tst-printf-bz18872) on HPPA with -ggdb3
https://sourceware.org/bugzilla/show_bug.cgi?id=29401 --- Comment #2 from Sam James --- (In reply to Sam James from comment #1) > Versions: > - gcc (Gentoo 11.2.1_p20220115 p4) 11.2.1 20220115 > - GNU ld (Gentoo 2.37_p1 p2) 2.37 > - kernel 5.19.0-rc4 I can also hit it with gcc (Gentoo 11.3.0 p4) 11.3.0 and GNU ld (Gentoo 2.38 p4) 2.38. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29401] Hang in `as` when compiling large printf() file (from glibc's tst-printf-bz18872) on HPPA with -ggdb3
https://sourceware.org/bugzilla/show_bug.cgi?id=29401 Sam James changed: What|Removed |Added Summary|Hang when compiling large |Hang in `as` when compiling |printf() file (from glibc's |large printf() file (from |tst-printf-bz18872) on HPPA |glibc's tst-printf-bz18872) |with -ggdb3 |on HPPA with -ggdb3 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25333] GAS is slow processing units compiled with -fdebug-types-sections containing many types
https://sourceware.org/bugzilla/show_bug.cgi?id=25333 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 gas/29401] Hang in `as` when compiling large printf() file (from glibc's tst-printf-bz18872) on HPPA with -ggdb3
https://sourceware.org/bugzilla/show_bug.cgi?id=29401 --- Comment #3 from Alan Modra --- (In reply to Sam James from comment #0) > It hangs at the end invoking `as`. Then you should attach the .s file. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29369] [2.39 Regression] ld: internal error ../../ld/ldlang.c 6452 on powerpc64le-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=29369 --- Comment #5 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=5d471bd907be60e9858b22cdf4fd10ddc0f6ee1a commit 5d471bd907be60e9858b22cdf4fd10ddc0f6ee1a Author: Alan Modra Date: Mon Jul 25 09:25:49 2022 +0930 Re: PowerPC64 .branch_lt address On seeing PR29369 my suspicion was naturally on a recent powerpc64 change, commit 0ab80031430e. Without a reproducer, I spent time wondering what could have gone wrong, and while I doubt this patch would have fixed the PR, there are some improvements that can be made to cater for user silliness. I also noticed that when -z relro -z now sections are created out of order, with .got before .plt in the section headers but .got is laid out at a higher address. That's due to the address expression for .branch_lt referencing SIZEOF(.got) and so calling init_os (which creates a bfd section) for .got before the .plt section is created. Fix that by ignoring SIZEOF in exp_init_os. Unlike ADDR and LOADADDR which need to reference section vma and lma respectively, SIZEOF can and does cope with a missing bfd section by returning zero for its size, which of course is correct. PR 29369 * ldlang.c (exp_init_os): Don't create a bfd section for SIZEOF. * emulparams/elf64ppc.sh (OTHER_RELRO_SECTIONS_2): Revise .branch_lt address to take into account possible user sections with alignment larger than 8 bytes. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29401] Hang in `as` when compiling large printf() file (from glibc's tst-printf-bz18872) on HPPA with -ggdb3
https://sourceware.org/bugzilla/show_bug.cgi?id=29401 --- Comment #4 from Sam James --- (In reply to Alan Modra from comment #3) > (In reply to Sam James from comment #0) > > It hangs at the end invoking `as`. > > Then you should attach the .s file. Originally, I didn't get a .s because I was using -pipe (which is why the `as` process was hanging, I guess, as it was waiting for GCC to feed it something). If I omit -pipe, I get the same hanging, but: ``` 22453 pts/5Ss 0:00 \_ -/bin/bash 22926 pts/5S+ 0:00 | \_ hppa2.0-unknown-linux-gnu-gcc -march=2.0 -fdiagnostics-show-option -ggdb3 -O2 -Wl,-O1 -Wl,--as-needed foo.c -v 22927 pts/5R+ 0:49 | \_ /usr/libexec/gcc/hppa2.0-unknown-linux-gnu/11.2.1/cc1 -quiet -v -dD foo.c -quiet -dumpdir a- -dumpbase foo.c -dumpbase-ext .c -march=2.0 -ggdb3 -O2 -version -fdiagnostics-show-option -o /tmp/ccuAnphe.s ``` If I try to run `as` on a copied version of /tmp/ccuAnphe.s (attached it anyway for completeness), it runs quickly and exits without an issue. So I guess the issue is actually GCC? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29401] Hang in `as` when compiling large printf() file (from glibc's tst-printf-bz18872) on HPPA with -ggdb3
https://sourceware.org/bugzilla/show_bug.cgi?id=29401 --- Comment #5 from Sam James --- Created attachment 14229 --> https://sourceware.org/bugzilla/attachment.cgi?id=14229&action=edit ccuAnphe.s -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29369] [2.39 Regression] ld: internal error ../../ld/ldlang.c 6452 on powerpc64le-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=29369 --- Comment #6 from cvs-commit at gcc dot gnu.org --- The binutils-2_39-branch branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=97acb51d6ac5b3e09b5817edc7a41678d96e945c commit 97acb51d6ac5b3e09b5817edc7a41678d96e945c Author: Alan Modra Date: Mon Jul 25 09:25:49 2022 +0930 Re: PowerPC64 .branch_lt address On seeing PR29369 my suspicion was naturally on a recent powerpc64 change, commit 0ab80031430e. Without a reproducer, I spent time wondering what could have gone wrong, and while I doubt this patch would have fixed the PR, there are some improvements that can be made to cater for user silliness. I also noticed that when -z relro -z now sections are created out of order, with .got before .plt in the section headers but .got is laid out at a higher address. That's due to the address expression for .branch_lt referencing SIZEOF(.got) and so calling init_os (which creates a bfd section) for .got before the .plt section is created. Fix that by ignoring SIZEOF in exp_init_os. Unlike ADDR and LOADADDR which need to reference section vma and lma respectively, SIZEOF can and does cope with a missing bfd section by returning zero for its size, which of course is correct. PR 29369 * ldlang.c (exp_init_os): Don't create a bfd section for SIZEOF. * emulparams/elf64ppc.sh (OTHER_RELRO_SECTIONS_2): Revise .branch_lt address to take into account possible user sections with alignment larger than 8 bytes. (cherry picked from commit 5d471bd907be60e9858b22cdf4fd10ddc0f6ee1a) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29401] Hang in `as` when compiling large printf() file (from glibc's tst-printf-bz18872) on HPPA with -ggdb3
https://sourceware.org/bugzilla/show_bug.cgi?id=29401 Alan Modra changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #6 from Alan Modra --- > So I guess the issue is actually GCC? Yes, clearly. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29401] Hang in `as` when compiling large printf() file (from glibc's tst-printf-bz18872) on HPPA with -ggdb3
https://sourceware.org/bugzilla/show_bug.cgi?id=29401 --- Comment #7 from Sam James --- (In reply to Alan Modra from comment #6) > > So I guess the issue is actually GCC? > Yes, clearly. Yeah, I see it now. Apologies. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29401] Hang in `as` when compiling large printf() file (from glibc's tst-printf-bz18872) on HPPA with -ggdb3
https://sourceware.org/bugzilla/show_bug.cgi?id=29401 Sam James changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=106431 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29369] [2.39 Regression] ld: internal error ../../ld/ldlang.c 6452 on powerpc64le-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=29369 --- Comment #7 from Alan Modra --- (In reply to Matthias Klose from comment #4) > no, I also updated the compiler once. A pity. Oh well. As far as I could tell from the build logs you were not building with -z relro -z now, but if that was the case then the ldlang.c fix I've just committed (fixing .got/.plt order) is relevant and a plausible fix for the assertion fail. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/5149] PT_GNU_RELRO having PF_R|PF_E even when no section in it needs exec is a ld bug
https://sourceware.org/bugzilla/show_bug.cgi?id=5149 Alan Modra changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #34 from Alan Modra --- I believe this was fixed for binutils a long time ago. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29376] multiple definition of weak symbols on MinGW toolchain
https://sourceware.org/bugzilla/show_bug.cgi?id=29376 --- Comment #2 from Bin Meng --- Using MSYS2 MinGW64 native toolchain x86_64-w64-mingw32-gcc (version 12.1.0), the attached test case can build successfully. Not sure if this issue is fixed in the MSYS2 toolchain, or is just simply the new GCC version 12.1.0 fixed the issue? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29376] multiple definition of weak symbols on MinGW toolchain
https://sourceware.org/bugzilla/show_bug.cgi?id=29376 --- Comment #3 from Bin Meng --- Please ignore above comments about the MSYS2 mingw native toolchain. There should be something wrong my test environment. -- You are receiving this mail because: You are on the CC list for the bug.
