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

[João Matos]

I'll be able to help on this with reviewing and testing.

On Thu, Oct 4, 2012 at 8:03 PM, Timur Iskhodzhanov <timurrrr at google.com>wrote:

> Why do you need RTTI for v*tables?
> I think we can start with no-RTTI
> 04.10.2012 22:31 пользователь "r4start" <r4start at gmail.com> написал:
>
> 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.
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>


-- 
João Matos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121004/87182181/attachment.html>