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

[r4start]

On 04/10/12 23:03, Timur Iskhodzhanov wrote:
>
> Why do you need RTTI for v*tables?
> I think we can start with no-RTTI
>
We can skip this step, but vf-table contains pointer to RTTI info.
Also it can be done separately. In vf-table we can store nullptr for 
RTTI and when RTTI will be done we`ll put pointer to it.
> 04.10.2012 22:31 пользователь "r4start" <r4start at gmail.com 
> <mailto: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.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121005/4f5aa275/attachment.html>