[llvm-dev] VC C++ demangler

Qian Hong via llvm-dev llvm-dev at lists.llvm.org
Tue Jun 27 01:17:59 PDT 2017


Sorry for didn't post earlier, has anyone checked
http://mingw-w64.sourceforge.net/libmangle/ ?

Also the Wine project has some code which might be useful as reference /
test case:

https://github.com/wine-mirror/wine/blob/master/dlls/msvcrt/undname.c
https://github.com/wine-mirror/wine/blob/master/dlls/msvcrt/tests/cpp.c#L1098




On Tue, Jun 27, 2017 at 3:53 PM, Rui Ueyama via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I uploaded a FYI patch (not intended for submission) as
> https://reviews.llvm.org/D34667. If you want to take a look and comment
> on its design, please do so. Thanks!
>
> On Fri, Jun 23, 2017 at 5:25 PM, Zachary Turner <zturner at google.com>
> wrote:
>
>> Please add me on reviews.  BTW, even differing in whitespace might cause
>> problems, I know their tools have some builtin assumptions about whitespace
>> in type names.  How deeply engrained this is is not clear though.
>>
>> On Fri, Jun 23, 2017 at 10:10 AM Rui Ueyama via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> FYI, I started writing a demangler. I think I can send an initial patch
>>> to review in a few days.
>>>
>>> On Tue, Jun 20, 2017 at 11:07 AM, Rui Ueyama <ruiu at google.com> wrote:
>>>
>>>> On Tue, Jun 20, 2017 at 10:51 AM, Robinson, Paul <
>>>> paul.robinson at sony.com> wrote:
>>>>
>>>>> If it's only whitespace differences, that's easy to accommodate.  If
>>>>> there are other cases that don't work, maybe don't use this tactic for
>>>>> those, if we have a good reason for being different.  As they say, don't
>>>>> throw the baby out with the bathwater.
>>>>>
>>>>
>>>> I'll try to keep the difference only in whitespace.
>>>>
>>>>
>>>>> --paulr
>>>>>
>>>>>
>>>>>
>>>>> *From:* David Blaikie [mailto:dblaikie at gmail.com]
>>>>> *Sent:* Tuesday, June 20, 2017 10:39 AM
>>>>> *To:* Rui Ueyama; Robinson, Paul
>>>>> *Cc:* Martin J. O'Riordan; llvm-dev at lists.llvm.org
>>>>> *Subject:* Re: [llvm-dev] VC C++ demangler
>>>>>
>>>>>
>>>>>
>>>>> Yeah, may well be the case - I don't /think/ LLVM quite matches the
>>>>> exact syntax of the GCC demangler either (I seem to recall constants as
>>>>> non-type template parameters were a bit different).
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 20, 2017 at 10:36 AM Rui Ueyama <ruiu at google.com> 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
>>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>


-- 
Regards,
Qian Hong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170627/bf76c3ca/attachment.html>


More information about the llvm-dev mailing list