[cfe-dev] Writing a MSVC-compatible vtable generator

[r4start]

On 04/10/2012 21:55, John McCall wrote:
> On Oct 4, 2012, at 9:57 AM, r4start wrote:
>>> Hello Peter, John,
>>>
>>> As of r159090, Clang generated MSVC-incompatible vtables.
>>> [Currently it generates the same intermediate objects but due to
>>> r159091 they are not emitted into the object file at all]
>>>
>>> I'd like to fix that and get MSVC-compatible vtables, vbtables etc.
>>>
>>> Can you give some recommendations on how to achieve that?
>>>
>>> VTableBuilder.{h,cpp} are 3K lines total which scares me a bit :)
>>>
>>> Options:
>>> a) Duplicate a lot of code and have MSVTableComponent, MSVTableLayout,
>>> MSVTableContext, MSVTableBuilder etc.
>>>      and call different methods of different classes in the
>>> {Itanium,Microsoft}CXXABI::EmitVTables
>>>     Disadvantage: a LOT of code duplication
>>>     Advantage: implementations are completely separate, no conflicts,
>>> little chance of breaking the Itanium ABI.
>>>     My opinion: don't like it.
>>>
>>> b) Inject a virtual interface at some point and provide two
>>> implementations (Itanium, Microsoft),
>>>      similar to CGCXXABI vs ItaniumCXXABI vs MicrosoftCXXABI.
>>>     If so, can you give your thoughts about which class should be abstracted out?
>>>     Unfortunately, I'm not very familiar with the code.
>>>     My best guess is that VTableLayout should be compatible with any
>>> ABI (right?) and it's the VTableContext that should be converted into
>>> an interface.
>>>     It might be that case that VTableContext is compatible with any ABI
>>> and it's VTableBuilder that should be converted into an interface.
>>>     In any case, the current Itanium-specific parts of the
>>> implementation should then be moved to ItaniumVTableXXX.
>>>
>>>     Advantage: "the OOP way"
>>>     Disadvantage: may make further progress harder if ItaniumVTableXXX
>>> and MicrosoftVTableXX implementations are substantially different due
>>> to different terminology/layout in the ABI.
>>>     My opinion: the way to go, but the interface injection point should
>>> be well thought of.
>> We can write some general interface - CGVTable(for example).
>> ItaniumVtable and MicrosoftVTable will implement this interface.
>> For some specific things we can do next thing:
>>
>> class CGVtable {
>> // ...
>>
>> virtual SomeSpecificInterface *get() = 0;
>>
>> // ..
>> };
>>
>> class MicrosoftVTable : CGVTable, SomeSpecificInterface {
>>
>> virtual SomeSpecificInterface *get() { return this; }
>>
>> };
>>
>> This method works fine in our code for some microsoft specific mangling features.
>>> c) Add a bunch of "if (ABI == Itanium) {} else if (ABI == Microsoft)
>>> {}" conditions to VTableBuilder.cpp
>>>     It's ugly but works at least in the simple cases (e.g. non-virtual
>>> inheritance)
>> We have working code of vf-table & vb-table generation and we use this variant.
>> This check will be needed only in few places.
>> If you want to see how it done I can give you link to our github repo. Also you will find previous variant in our microsoft mangling code. Code is not very good, but it works.
> If you've found that this is working for the full generality, then great.  I just didn't want us to commit to an interface which was going to immediately fall apart when we needed to support vbtbls.
>
>
We do not have enough time for testing. So I can`t say that this code 
fully correct it need more testing.
If MS RTTI info can be committed in trunk then I can start publish small 
patches with RTTI.
I think after that vf-table/vb-table implementation can be started.

  - Dmitry Sokolov.