[cfe-dev] [MSVC] Microsoft mangling failures

Timur Iskhodzhanov timurrrr at google.com
Wed Nov 14 04:04:59 PST 2012


I think the situation on x86 is gradually improving on the "as needed"
basis, at least I can build substantial parts of Chromium with Clang.

If you have any particular cases which are really blockers and they
seem easy to fix, please file bugs and provide test cases.

Ideally, "a real blocker" is when link.exe prints out an "undefined
symbol" error when you try to link Clang-built obj with a CL-built
obj.
In this case, it's obvious that we're doing something wrong and it's
obvious what we should do instead.

If you can't provide such a test case - well, it might not be that important :)

The only exception is probably RTTI as is basically not supported with
"-cxx-abi microsoft" at the moment and it's doesn't add much value to
file RTTI-mangling bugs for a neither supported nor planned feature.

--
Timur

On Wed, Nov 14, 2012 at 12:44 AM, pravic <ehysta at gmail.com> wrote:
>> I would make a small example app using all of these
>> constructs and see how MSVC handles mangling them and compare that to
>> what clang currently emits
>
> I tested CodeGenCXX folder with MSVC and Clang. Some stats:
>  464 tests, 63 assertion failures, 5 crash dumps, around 80 tests have a
> mangling mismatches against VC++.
>
> Of course, some of mismatches is a check script failures, but whole state of
> the situation
> (in context of windows support) looks sadly.
>
> Mismatches:
> x64 mode: http://bit.ly/W2hBal
> x86 mode: http://bit.ly/W2hFqM
> (1st line is demangled name, 2nd is mangled by VC, 3rd is by Clang)
>
>> I would focus on function parameters (public, protected, private and
>> non-instance), and then return types first.  Then I'd focus on global
>> variables
>
> Posted at Phabricator.
>
>
> On 13.11.2012 1:31, Aaron Ballman wrote:
>>
>> I would break the problem into several smaller parts.  For right now,
>> I'd ignore __ptr64 and __ptr32 entirely and focus solely on what it
>> takes to get Microsoft mangling of pointers correct for x86-64 builds.
>>   I would focus on function parameters (public, protected, private and
>> non-instance), and then return types first.  Then I'd focus on global
>> variables.  I would make a small example app using all of these
>> constructs and see how MSVC handles mangling them and compare that to
>> what clang currently emits.  That should give you a good start on what
>> items need to be tackled -- make a test case for each item that needs
>> to be handled (knowing they'll fail), and then work on the code until
>> it succeeds.
>>
>> Once we've gotten pointer mangling correct, we can start to worry
>> about type attributes like __ptr64 and __ptr32.
>>
>> ~Aaron
>>
>> On Mon, Nov 12, 2012 at 3:15 PM, pravic<ehysta at gmail.com>  wrote:
>>>
>>>    Another problem.
>>>
>>>    For example,
>>>
>>>
>>>      void* __ptr32 pub( int * p)
>>>
>>>
>>>
>>>    Here we have the one explicit attribute, but
>>> MicrosoftCXXNameMangler::mangleType operates by **QualType**, which have no
>>> attributes, only qualifiers.
>>>
>>>    The **NamedDecl** have them, but where is connection between some
>>> attribute in //declaration// and specific type? Attribute also have a source
>>> location, but **QualType** no.
>>>
>>> http://llvm-reviews.chandlerc.com/D101
>>> _______________________________________________
>>> cfe-commits mailing list
>>> cfe-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev



More information about the cfe-dev mailing list