> (for example, the demangler is crash-prone so GDB installs a SEGV handler when invoking it)<p>Yikes.<p>> There were some helpful comments that I believe were true at one point that explained why this was useful. However, I instrumented GDB and found that less than 10% of the cached DIEs were ever re-used. Computing and allocating them was largely a waste, just to support a few lookups. And, nearly every DIE that was ever looked up was done so on behalf of a single call — so the cache was nearly useless.<p>It's interesting if this partial DIE reuse is a function of the binary being loaded in GDB - or is it a hardcoded analysis that's common to all binaries?<p>I'm curious to know more about the test suite that underlies these instrumentations - presumably there's a representative sample of DWARF-containing binaries that represent the majority of use cases, but are there perhaps pathological cases for which the DIE caching mechanism is essential for reasonable startup time? Maybe it's these pathological cases that motivated the caching mechanism in the first place - and perhaps they're just not included in the test suite used for instrumentation.
Very cool!<p>The author claims in a comment that the fixes missed the branch for GDB 12, but are planned for inclusion in the GDB 13 release. The GDB release schedule [1] does not list a planned date for that release but I believe 12 has recently happened.<p>[1] <a href="https://www.sourceware.org/gdb/schedule/" rel="nofollow">https://www.sourceware.org/gdb/schedule/</a>