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

[David Blaikie via cfe-dev]

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/ec54278e/attachment.html>