zyxhere💠<[email protected]> writes: > On Sun, 2025-11-16 at 10:42 +0000, Sam James wrote: >> 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 > > For clang > https://clang.llvm.org/docs/SourceBasedCodeCoverage.html#running-the-instrumented-program > suggests to use the -Wl,--build-id LDFLAG, does gcc not support this > too?
We want to make sure they're always used and not have users accidentally forget to include them. Some packages also strip LDFLAGS if they're very sensitive to flag use but we would still want build IDs there. For Clang, we will put it in /etc/clang config files.
