As the person who, eons ago, wrote a bunch of the the GDB code for this
C++
ABI support, and as someone who helped with DWARF support in both GDB
and
GCC, let me try to propose a useful path forward (in the hopes that
someone
will say "that's horrible, do it this <clearly better way> instead")
Here are the constraints i believe we are working with.
1. GDB should work with multiple DWARF producers and multiple C++
compilers
implementing the C++ ABI
2. There is no canonical demangled format for the C++ ABI
3. There is no canoncial target demangler you can say everyone should
use
(and even if there was, you don't want to avoid debugging working
because
someone chose not to)
4. You don't want to slow down GDB if you can avoid it
5. Despite them all implementation the same ABI, it's still possible to
distinguish the producers by the producer/compiler in the dwarf info.
Given all that:
GDB has ABI hooks that tell it what to do for various C++ ABIs. This is
how
it knows to call the right demangler for gcc v3's abi vs gcc v2's abi.
and
handle various differences between them.
See gdb/cp-abi.h
The IMHO, obvious thing to do here is: Handle the resulting demangler
differences with 1 or more new C++ ABI hooks.
Or, introduce C++ debuginfo producer hooks that the C++ ABI hooks use
if
folks want it to be separate.
Once the producer is detected, fill in the hooks with a set of
functions
that does the right thing.
I imagine this would also clean up a bundle of hacks in various parts
of
gdb trying to handle these differences anyway (which is where a lot of
the
multiple symbol lookups/etc that are often slow come from.
If we just detected and said "this is gcc 6, it behaves like this", we
wouldn't need to do that)
In case you are worried, you will discover this is how a bunch of stuff
is
done and already contains a ball of hacks.
Using hooks would be, IMHO, a significant improvement.