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

[Timur Iskhodzhanov]

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.

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)

   Advantage: very easy to fix simple cases
   Disadvantage: not "the OOP way" + may be the most complex way to
create a complete solution

Looking forward for your ideas!
Thanks,
Timur Iskhodzhanov,
Google Russia