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

[Daniel Berlin via llvm-dev]

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, 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180306/7c30f6f6/attachment.html>