I've enabled splitdebug and compressdebug for some packages. Something broke the compressdebug feature, I'm really not sure what, I'm guessing some bug introduced in portage, as the bug occured to me just now as Python was rebuild for me yesterday. Without compressdebug, the debugsyms (including splitdebug) can be read just fine. Only the compression seems to be broken. Below are the symptoms: % gdb /usr/bin/python3.6 Reading symbols from /usr/bin/python3.6...done. = gdb>> r Starting program: /usr/bin/python3.6 process 40757 is executing new program: /usr/bin/python3.6m BFD: /usr/lib64/debug/usr/bin/python3.6m.debug: unable to initialize decompress status for section .debug_aranges BFD: /usr/lib64/debug/usr/bin/python3.6m.debug: unable to initialize decompress status for section .debug_aranges BFD: /usr/lib64/debug/usr/bin/python3.6m.debug: unable to initialize decompress status for section .debug_aranges BFD: /usr/lib64/debug/usr/bin/python3.6m.debug: unable to initialize decompress status for section .debug_aranges BFD: /usr/lib64/debug/usr/bin/python3.6m.debug: unable to initialize decompress status for section .debug_aranges warning: `/usr/lib64/debug/usr/bin/python3.6m.debug': can't read symbols: file format not recognized. BFD: /usr/lib64/debug/usr/lib64/libpython3.6m.so.1.0.debug: unable to initialize decompress status for section .debug_aranges BFD: /usr/lib64/debug/usr/lib64/libpython3.6m.so.1.0.debug: unable to initialize decompress status for section .debug_aranges BFD: /usr/lib64/debug/usr/lib64/libpython3.6m.so.1.0.debug: unable to initialize decompress status for section .debug_aranges BFD: /usr/lib64/debug/usr/lib64/libpython3.6m.so.1.0.debug: unable to initialize decompress status for section .debug_aranges BFD: /usr/lib64/debug/usr/lib64/libpython3.6m.so.1.0.debug: unable to initialize decompress status for section .debug_aranges [1] + 40754 suspended (tty output) gdb -q =python3 it's killed by SIGSTOP. % gdb /usr/bin/python3.7 Reading symbols from /usr/bin/python3.7...BFD: /usr/lib64/debug/usr/bin/python3.7m.debug: unable to initialize decompress status for section .debug_aranges BFD: /usr/lib64/debug/usr/bin/python3.7m.debug: unable to initialize decompress status for section .debug_aranges BFD: /usr/lib64/debug/usr/bin/python3.7m.debug: unable to initialize decompress status for section .debug_aranges BFD: /usr/lib64/debug/usr/bin/python3.7m.debug: unable to initialize decompress status for section .debug_aranges BFD: /usr/lib64/debug/usr/bin/python3.7m.debug: unable to initialize decompress status for section .debug_aranges `/usr/lib64/debug/usr/bin/python3.7m.debug': can't read symbols: file format not recognized. = gdb>> quit errors are detected right away.
Please post 'emerge --info'.
Created attachment 568174 [details] emerge --info
(In reply to Jonas Jelten from comment #2) > Created attachment 568174 [details] > emerge --info ... > sys-devel/binutils: 2.32::gentoo Thank you! I suspect it's a fallout of binutils-2.32 update: https://sourceware.org/PR23919 We will need to wait for a new gdb release based on binutils-2.32 (or fixes backported).
gdb-9999 works fine with compressdebug, so it can be used by users as a "workaround" till the new version is released or the fix is backported.
*** Bug 680130 has been marked as a duplicate of this bug. ***
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a5b9b8dd1ffbc3d326bc0b13315bcdd411d7a044 commit a5b9b8dd1ffbc3d326bc0b13315bcdd411d7a044 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-03-12 21:32:35 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-03-12 21:35:34 +0000 sys-devel/gdb: bump up to 8.3.50.20190312, bug #679564 binutils-2.32 fixed long-standing bug in handling compressed sections alignment: https://sourceware.org/PR23919 Unfortunately it broke older binutils and gdb versions as they don't handle the correct section format. The change pulls in gdb snapshot from recently created gdb-8.3 branch. That should allow handling of debug data created by binutils-2.32. Reported-by: Jonas Jelten Closes: https://bugs.gentoo.org/679564 Package-Manager: Portage-2.3.62, Repoman-2.3.12 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> sys-devel/gdb/Manifest | 1 + sys-devel/gdb/gdb-8.3.50.20190312.ebuild | 256 +++++++++++++++++++++++++++++++ 2 files changed, 257 insertions(+)
*** Bug 683220 has been marked as a duplicate of this bug. ***
this also happens with binutils-2.31.1-r5 and gdb-8.1-r2 fixing this would mean to emerge gdb-8.3.50.20190312-r1 then?
(In reply to tt_1 from comment #8) > this also happens with binutils-2.31.1-r5 and gdb-8.1-r2 > > fixing this would mean to emerge gdb-8.3.50.20190312-r1 then? are you absolutely sure about this? binutils-2.31.1-r5 was specificially created *not* to show this problem
Since this is a linking issue, the package has to be rebuild with the new binutils-2.31.1-r5. Which I just did and all is fine.
