Re: gdb 8.x - g++ 7.x compatibility

Simon Marchi
2018-02-07T13:44:39Z

On 2018-02-07 02:21, Daniel Berlin wrote:
> 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.

Hi Daniel,

Thanks for chiming in.

This addresses the issue of how to do good software design in GDB to
support different producers cleanly, but I think we have some issues
even before that, like how to support g++ 7.3 and up. I'll try to
summarize the issue quickly. It's now possible to end up with two
templated classes with the same name that differ only by the signedness
of their non-type template parameter. One is Foo<int N> and the other
is Foo<unsigned int N> (the 10 is unsigned). Until 7.3, g++ would
generate names like Foo<10> for the former and names like Foo<10u> for
the later (in the DW_AT_name attribute of the classes' DIEs). Since
7.3, it produces Foo<10> for both.

When GDB wants to know the run time type of an object, it fetches the
pointer to its vtable, does a symbol lookup to get the linkage name and
demangles it, which gives a string like "vtable for Foo<10>" or "vtable
for Foo<10u>". It strips the "vtable for " and uses the remainder to do
a type lookup. Since g++ 7.3, you can see that doing a type lookup for
Foo<10> may find the wrong type, and doing a lookup for Foo<10u> won't
find anything.

So the problem here is how to uniquely identify those two classes when
we are doing this run-time type finding operation (and probably in other
cases too).

Simon