Hi, We are hoping in toolchain@ to re-enable default build IDs (rationale below). Some more testing would be appreciated before planning and rolling things out further. Build IDs are a hash added to a binary by the linker to allow distinguishing between binaries built with the same code (and toolchain) or not.
If you're able and willing, please enable default build IDs in GCC with: # mkdir /etc/portage/env/sys-devel/ # echo '# https://bugs.gentoo.org/953869' >> /etc/portage/env/sys-devel/gcc # echo 'EXTRA_ECONF="${EXTRA_ECONF} --enable-linker-build-id"' >> /etc/portage/env/sys-devel/gcc # emerge -v1 sys-devel/gcc Then either let things gradually get rebuilt on upgrades or do -e @world. I haven't looked at an equivalent for Clang yet but it should be just a small addition to llvm-core/clang-common (and users can test before that by editing /etc/clang). I don't expect any trouble. >= Portage 3.0.69 seeds build IDs if debugedit is available to avoid collisions between packages where some library is bundled. (I expect we will make debugedit a dependency of Portage to make getting debug information more reliably withut hassle, especially given it's so lightweight.) As for rationale, it's detailed in https://bugs.gentoo.org/953869, but in summary: * faster debug info loading in gdb; * gdb handles looking up debug info by hash (build ID) far better than by path; * perf and gdb can both cache based on build ID; * KDE's crash reporter, kde-plasma/drkonqi, requires it; * it allows distributing debug info for binpkgs and for handling the case where a binary was upgraded on the system but you have an old process running still and it needs to be debugged. Generally, debugging and analysis tools are starting to expect build IDs and are surprised when they aren't there. I stumbled upon a few things that started working (like gdb's index-cache) unexpectedly with this work. thanks, sam
signature.asc
Description: PGP signature
