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

[David Blaikie via llvm-dev]

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


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

Can't say I'm following this part.. well, sort of following. But doesn't
seem relevant to Roman's situation, which isn't about GDB.

I think the only problem being addressed for GDB is the polymorphic case.
The ability to match non-polymorphic types (with what, I'm not sure - not
vtables in any case) is motivated by Roman's other examples of IR, etc, not
GDB's dynamic type discovery.

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180306/0fb0435f/attachment.html>