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

On 7 February 2018 at 15:07, Manfred <[email protected]> wrote:
>
>
> On 02/07/2018 02:44 PM, Simon Marchi wrote:
>>
>> 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
>
>
> Hi all,
>
> In the perspective of "type identity", the way I see it the issue has a few
> parts:
>
> 1) How GCC compiles such templates
> 2) How GCC emits debugging information via -g
> 3) How such information is interpreted (and merged with the compiled code)
> by GDB
>
> Regarding 1) and 2), IMHO I think that there should be a one-to-one
> relationship between the compiled code output and debug info:
>
> This means that if GCC compiles such templates into two different
> classes[1], it should generate two different type identifiers.

What do you mean by "such templates"? There have been several
different examples in the thread, which should be handled differently.

> Conversely, if it compiles the templates into the same class, then a single
> identifier should be emitted for the single class compiled.
> (This goes besides the point of what the standard dictates[2])
>
> If I understand it right, currently the issue is that gcc emits two types
> with the same debug identifier.
>
> Regarding 3), I think that after 1) and 2) are set up, GDB should be able to
> find the correct type definition (using the most appropriate design choice).
>
> Hope this helps,

Not really :-)

You're basically just saying "GCC and GDB should do the right thing"
which is a statement of the obvious.


> [1] According to the findings of Simon, this appears to be the case with
> clang, older GCC, and current GCC master. Do I understand this right?

As I said above, it's not clear what you're referring to.

> [2] About handling both templates instantiation as a single class, I think
> that if GCC wants to emit a single class, then its argument type
> instantiation should be well-definined,i.e. independent of the order of
> declaration - see the findings from Simon earlier in this thread where you
> could get the program output either -10 or 4294967286 depending on which
> declaration would come first.

That's just a GCC 7 bug in the handling of auto template parameters,
see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79092
It's not really relevant here, and is already fixed on trunk.