[llvm-dev] Emiting linkage names for Types to Debuginfo (C++ RTTI support in GDB/LLDB)

[Daniel Berlin via llvm-dev]

On Tue, Mar 6, 2018 at 9:46 AM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
> On Tue, Mar 6, 2018 at 9:28 AM Daniel Berlin <dberlin at dberlin.org> wrote:
>
>> On Tue, Mar 6, 2018 at 9:22 AM, David Blaikie <dblaikie at gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, Mar 6, 2018 at 8:39 AM Daniel Berlin <dberlin at dberlin.org>
>>> wrote:
>>>
>>>> On Mon, Mar 5, 2018 at 11:55 PM, Roman Popov <ripopov at gmail.com> wrote:
>>>>
>>>>> I don't understand how extra vtable ref DIE will help in case on
>>>>> non-polymorphic classes. If you remove virtual destructor from example,
>>>>> vtable won't be generated for class, but DWARF will still have incorrect
>>>>> ambiguous names for types.
>>>>>
>>>> 1. Calling them incorrect is ... not right.  As Andrew quoted on the
>>>> gdb mailing list, this is what DWARF specifies should happen,
>>>>
>>>
>>> Might be helpful to point to/include any details cited here for the
>>> purpose of this conversation - a bit hard for the rest of us to follow
>>> along.
>>>
>>>
>>
>> "
>> Reading http://wiki.dwarfstd.org/index.php?title=Best_Practices:
>> the DW_AT_name attribute should contain the name of the corresponding
>> program object as it appears in the source code, without any
>> qualifiers such as namespaces, containing classes, or modules (see
>> Section 2.15). A consumer can easily reconstruct the fully-qualified
>> name from the DIE hierarchy. In general, the value of DW_AT_name
>> should be such that a fully-qualified name constructed from the
>> DW_AT_name attributes of the object and its containing objects will
>> uniquely represent that object in a form natural to the source
>> language."
>>
>>
>>
>>> so they are correct by spec. If you believe the spec is wrong, file an
>>>> issue on the DWARF web site and discuss it on the mailing list, and bring
>>>> back the consensus of the committee as to what to do :)
>>>>
>>>
>>> The ambiguous names are probably incorrect - having two distinct types
>>> that have the same name's not really going to work out well for a consumer.
>>> (so having the distinct types foo<11u> and foo<11> in source both produce a
>>> DWARF type named "foo<11>" I'd say is a bug that ought to be fixed - as is
>>> any other case where the names become ambiguous, otherwise matching up
>>> types between TUs would become impossible, which would be not good)
>>>
>>
>> I'm sure the spec needs to be updated, i'm just saying "it's not wrong by
>> what the spec and best practices say to do right now".
>>
>
> Looks wrong to me.
>

>
It doesn't "uniquely represent" the object nor is it natural to the source
> language (foo<11> gets you the signed one, you'd have to write foo<11u> or
> foo<(unsigned)11> to get the unsigned one - yet Clang's DWARF currently
> names them both foo<11>).
>
>

Great, so fix clang/llvm to make it true :)
That still doesn't involve adding linkage names to everything.
If we can't fix it, that's worth a discussion with the DWARF folks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180306/34b99fa2/attachment.html>