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

[Roman Popov via cfe-dev]

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


And continuing the quote from same webpage:

*"For template instantiations, the DW_AT_name attribute should contain both
the source language name of the object and the template parameters that
distinguish one instantiation from another. The resulting string should be
in the natural form for the language, and should have a canonical
representation (i.e., different producers should generate the same
representation). For C++, the string should match that produced by the
target platform's canonical demangler; spaces should only be inserted where
syntactically required by the compiler."*

As I said, for about a year I thought that this is how it supposed to work.
Only after I upgraded compiler, I found all those issues.




> that you go to the DWARF mailing list and start a discussion about, rather
> than just proposing a solution.
> In my experience, the people there have thought a lot about all of these
> use cases, and you may in fact find a solution that doesn't require doing
> anything at all.


*nod* fair, might be worth it for the broader set of issues Roman seems to
> be dealing with (beyond the dynamic type identification issues that GDB
> demonstrates).



I can ping DWARF maillist about using DWARF as a reflection mechanism.
DWARF however is language-agnostic, and this seem to be C++ -specific issue.


2018-03-06 9:58 GMT-08:00 David Blaikie <dblaikie at gmail.com>:

>
>
> On Tue, Mar 6, 2018 at 9:49 AM Daniel Berlin <dberlin at dberlin.org> wrote:
>
>> On Tue, Mar 6, 2018 at 9:20 AM, Roman Popov <ripopov at gmail.com> wrote:
>>
>>> I wonder if  abi::__cxa_demangle guarantees unambigous names?
>>>>>
>>>>
>>>> No, it does not.
>>>>
>>>
>>> Interesting. Can you give an example of type where it fails?
>>>
>>
>> I can't construct one out of thin air, but i believe someone cited one to
>> you on the gdb mailing list.  It's entirely possible for the human readable
>> form of two symbols to be the same when the symbols are different.
>> I really just don't have the energy to copy the entire discussion on the
>> other mailing list here.
>>
>> More to the point, the ABI literally does not guarantee it, and different
>> demanglers for the Itanium ABI (there are a bunch) do different things for
>> human readable names.
>> You cite below gcc vs gcc, which is different versions of the same
>> demangler.  There are a bunch of Itanium C++ ABI implementations, including
>> demanglers and compilers, and i'd strongly caution you to remember that all
>> the world is not clang and GNU.
>>
>>
>>
>>
>>
>>> I'm currently working on hardware construction library for C++ (similar
>>> to Chisel (which is written in Scala)). And since C++ has no standardized
>>> reflection, I use DWARF as a source of reflection metadata. And in case of
>>> G++ 6.3, which seem to emit same name names as abi::__cxa_demangle, it has
>>> never failed so far in my case. And I have very diverse inputs.
>>> In fact I was working on it for about a year, and I was thinking that it
>>> how it supposed to work. Only after I upgraded to g++ 7 I've found out that
>>> both modern g++ and clang do not emit unambiguous debuginfo.
>>>
>>
>> This seems to be a different question than i thought you asked.
>> If you are asking "where will the demangled name between what
>> abi::__cxa_demangle and what GCC outputs in the debug info differ", it's
>> unlikely to differ if you use the same versions of both ;)
>>
>> But it will in some cases. Some bugs, some not.
>> Mangled names are not a panacea.  I think you also wildly underestimate
>> the cost of demangling every symbol in a large binary, for example, which
>> would required for your suggestion, as well as the size of these symbols,
>> etc. It's enough that people wrote a fast demangler, for example.  That's
>> just one issue.
>>
>> As for the rest, you are taking a perspective that is pretty strongly
>> focused on your use cases, and currently, DWARF is pretty focused on the
>> other ones.
>> If you want to convince the committee/others that it should give up on
>> the part of the best practices i cited, go for it.
>>
>> But you started by claiming this was necessary/important to fix the GDB
>> problems here, and it's simply not.  In fact, it would not fix most of them
>> without a serious change in the way these things operate, and at high cost.
>> Suggesting to change gdb, gcc, clang, to fit your non-debugger use case
>> is  taking a very big hammer and saying "it can also pound these nails".
>> While true, that doesn't mean you should.
>>
>> I'd strongly suggest, if you have concerns about the ability of DWARF to
>> handle your use cases without linkage names,
>>
>
> I think the only reason Roman's discussing ways that would work without
> linkage names is because you pretty firmly said that adding linkage names
> was a bad idea (for the original issue of dynamic class identification).
>
> Which, sure, it's an idea with some issues - but the alternative (vtable
> DIEs with address/ref) isn't without complications too - not to dismiss it,
> but to suggest having some real conversation about the tradeoffs seems
> worthwhile.
>
> & while the vtable DIE solution addresses the dynamic class identification
> case, it doesn't cover the other use cases Roman has in mind - other use
> cases that sound like they would be solved by having the linkage name of a
> type provided in the DWARF.
>
>
>> that you go to the DWARF mailing list and start a discussion about,
>> rather than just proposing a solution.
>>
>> In my experience, the people there have thought a lot about all of these
>> use cases, and you may in fact find a solution that doesn't require doing
>> anything at all.
>>
>
> *nod* fair, might be worth it for the broader set of issues Roman seems to
> be dealing with (beyond the dynamic type identification issues that GDB
> demonstrates).
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180306/1ee7d447/attachment.html>