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?
signature.asc
Description: This is a digitally signed message part
