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

[Daniel Berlin via cfe-dev]

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".


>
>
>> 2. The failure that was cited on the gdb mailing list only occurs on
>> polymorphic classes.   If you have it occurring on non-polymorphic classes,
>> that seems like a very different problem, and probably related to the fact
>> that GDB does not know how to assemble or parse C++ names properly in some
>> cases.  Otherwise, this would occur on literally every class you saw in
>> GDB, and that's definitely not the case:)
>>
>
> Sounds like Roman's talking about other use cases apart from GDB.
>

Yes.


>
>
>> The only reason linkage names would fix that issue is because they
>> provide an exact match to GDB's parsing failure.
>>
>
> Not sure I follow this - providing linkage names would provide a reliable
> mechanism to match the vtable symbol. There wouldn't need to be any
> parsing, or any failure of parsing involved.
>
> But, yes, addresses would be potentially a better description rather than
> having to match names in the object's symbol table.
>

I'm saying the only reason it would fix non-polymorphic classes is if gdb
is failing to parse names so that it can do die lookup properly.

GDB gives up in some cases and incorrectly says "lookup foo::bar::fred in
the global symbol namespace"  instead of "lookup fred inside class bar
symbol namespace".

In those cases, the linkage name would fix it because it will appear in the
global symbol namespace.
But it would also work if you just fixed the name parsing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180306/d4980545/attachment.html>