Faster GDB startup
tromey.com> (for example, the demangler is crash-prone so GDB installs a SEGV handler when invoking it)
Yikes.
> 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.
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?
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.
> > (for example, the demangler is crash-prone so GDB installs a SEGV handler when invoking it)
> Yikes.
I originally believed GDB must have quite a sophisticated SIGSEGV handler because when it exploded it was telling me that the crash was in the libiberty demangler.
I was disappointed to discover that this is entirely a special case - the handler is literally installed before the relevant calls into libiberty and then removed afterwards (though this behaviour can be turned off). Of course, this is a pragmatic solution when you know one component is more vulnerable.
This does mean there's a phenomenal number of `sigaction()` calls involved in GDB's debugging of C++. When investigating GDB with a time travel debugger (I was using UDB but I presume rr would have a similar experience unless they've optimised this case further) a large proportion of the history logged was just those syscalls.
>> (for example, the demangler is crash-prone so GDB installs a SEGV handler when invoking it) > > Yikes.
Is the demangler part of GDB? It can't be that hard™ to write a parser that doesn't crash, right? ^^
The demangler is part of libiberty (https://en.wikipedia.org/wiki/Libiberty)[1] It's part of binutils, which GDB is also part of.
[1] you link to it using "-liberty", which is cute.
I tend to agree that a parser really shouldn't crash here! But it does have to cope with arbitrary compiler's name mangling behaviour, which can itself be buggy. So the data it's ingesting can be slightly more "hostile" than I'd have expected.
The most notable occasion I saw the demangler crashing it was with a SIGSEGV after what looked like unbounded recursive calls into the demangling routines.
The developers I was working with at the time had a demangler of their own, which wasn't crashing on the same mangled symbol name...
Their diagnosis was that the mangled name itself was incorrect due to a compiler bug. Attempting to demangle the name would produce infinite expansion - in libiberty's parser, this meant unbounded recursion. In the alternative implementation it just filled the available buffer and bailed out.
(edit: fixed footnote)
extremely simple fix: limit the recursion depth.
Very cool!
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.