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

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

If you want an example, gdb's parser understands that Foo<unsigned
int> and
Foo<unsigned> are the same because it parses them properly.
It does not understand that Foo<2> and Foo<2u> are the same because
it
parses them incorrectly.

Fixing the parsing would fix the lookup issue in that case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932
etc
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180306/58d67549/attachment.html>

On Tue, Mar 6, 2018 at 9:36 AM Daniel Berlin <dberlin at dberlin.org>
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".
>>
>>
>>>
>>>
>>>> 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.
>>
>
>
> If you want an example, gdb's parser understands that Foo<unsigned
int>
> and Foo<unsigned> are the same because it parses them properly.
> It does not understand that Foo<2> and Foo<2u> are the same
because it
> parses them incorrectly.
>
Ah, but they aren't necessarily the same type. Clang (& GCC?) are
producing
two different types but naming them both Foo<2>. That's the ambiguity
Roman's referring to.

That's a bug in Clang (& GCC?) that ought to be fixed.

>
> Fixing the parsing would fix the lookup issue in that case.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932
> etc
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180306/f4b5a075/attachment.html>

On Tue, Mar 6, 2018 at 9:48 AM, David Blaikie <dblaikie at gmail.com>
wrote:
>
>
> On Tue, Mar 6, 2018 at 9:36 AM Daniel Berlin <dberlin at dberlin.org>
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".
>>>
>>>
>>>>
>>>>
>>>>> 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.
>>>
>>
>>
>> If you want an example, gdb's parser understands that
Foo<unsigned int>
>> and Foo<unsigned> are the same because it parses them properly.
>> It does not understand that Foo<2> and Foo<2u> are the same
because it
>> parses them incorrectly.
>>
>
> Ah, but they aren't necessarily the same type. Clang (& GCC?) are
> producing two different types but naming them both Foo<2>. That's
the
> ambiguity Roman's referring to.
>
> That's a bug in Clang (& GCC?) that ought to be fixed.
>
Agreed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180306/6e135de7/attachment.html>