[llvm-dev] VC C++ demangler

[David Majnemer via llvm-dev]

It has been a while since I have fought this stuff but, as I recall, there
is some relationship between the display name of a function in the debug
info and the result of demangling a symbol.
I think a good criteria is to have Clang's display name generation for
CodeView and our implementation of the demangler agree. This way we have an
explainable system and any discrepency we would want to correct would
result us in fixing both Clang and our demangler.

Even better idea: use the demangler to generate the display names in the
debug info. I am pretty sure this is what MSVC does.

On Tue, Jun 20, 2017 at 10:36 AM, Rui Ueyama via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Tue, Jun 20, 2017 at 10:17 AM, Robinson, Paul <paul.robinson at sony.com>
> wrote:
>
>> Just to be clear - once LLVM has its own demangler, it should probably
>> use it on all platforms, so there'd be no worry about different behavior
>> between LLVM on Windows and LLVM elsewhere.
>>
>> But that said, it's probably still important/worthwhile to make sure it's
>> consistent with the platform demangler.
>>
>>
>>
>> Personally I would be all for a unit test program that verified against
>> the Windows API when run on Windows, and against canned output on
>> non-Windows.
>>
>
> That was my preference too, but looks like getting the exact same results
> as the Windows API is not that easy nor worthwhile when it comes to
> arbitrary formatting rules. For example, IIRC, UnDecorateSymbolName
> generates not "int const* const* x" nor "int const * const * x" but "int
> const* const * x". This is simply odd, and I'd guess we don't want to
> mimic all these corner cases. So mixing our own demangler and the Windows
> demangler can cause unnecessary churn.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170620/bb2eb175/attachment.html>