[cfe-dev] Adding support for multiple non-virtual inheritance for -cxx-abi microsoft

[Timur Iskhodzhanov]

2013/4/8 Reid Kleckner <rnk at google.com>:
> On Mon, Apr 8, 2013 at 12:29 PM, Timur Iskhodzhanov <timurrrr at google.com>
> wrote:
>>
>> Q3) vtable layout
>> In Itanium ABI, there's one vtable for each class.
>> The non-virtual bases get address points somewhere in the middle of this
>> vtable.
>>
>> In Microsoft ABI, each base gets its own vtable, e.g. for the class C
>> we'll have
>> "C vtable for the A part" and "C vtable for the B part".
>>
>> We do the same in Clang, but that'd require some API changes to
>> VTableBuilder - i.e. you'll need to know a pair of classes to generate
>> a vtable, not just one.
>
>
> It's actually more than that.  Because a non-virtual base can appear more
> than once as a subobject, you need the base of the current subobject and the
> inheritance path to the most derived class.
>
> This came up in the virtual base table mangling patch I sent.  I assume
> we'll need similar logic at some point.
Agree!

>> We can go our own Itanium-like way and emit one vtable with address
>> points and still make this ABI-compatible (this is how my local patch
>> works) but I have a bad feeling that this may fail to work when we
>> start supporting virtual inheritance.
>
>
> IMO we should have two separate vtable builders, like we have two name
> manglers.  The comments on VTableContext::isMicrosoftABI() talk about adding
> such a layer.  They may be able to produce the same layout classes when
> done.  I think we can go incremental and cross that bridge later, but that's
> what we should aim for.
Sure.
I've added the comment btw :)

>> Do you have any thoughts or suggestions on this?
>>
>> --
>> Thanks!
>> Timur
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>