[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfe-dev
Subject:    Re: [cfe-dev] Adding support for multiple non-virtual inheritance for -cxx-abi microsoft
From:       Reid Kleckner <rnk () google ! com>
Date:       2013-04-08 16:46:54
Message-ID: CACs=tyJXVHQWU57XM+BSuuX6fC74caZFyKZHa0bUBdhMh24E8Q () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Mon, Apr 8, 2013 at 12:29 PM, Timur Iskhodzhanov <timurrrr@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.


> 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.


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

[Attachment #5 (text/html)]

<div dir="ltr">On Mon, Apr 8, 2013 at 12:29 PM, Timur Iskhodzhanov <span \
dir="ltr">&lt;<a href="mailto:timurrrr@google.com" \
target="_blank">timurrrr@google.com</a>&gt;</span> wrote:<br><div \
class="gmail_extra"><div class="gmail_quote"> <blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Q3) vtable \
layout<br> In Itanium ABI, there&#39;s one vtable for each class.<br>
The non-virtual bases get address points somewhere in the middle of this vtable.<br>
<br>
In Microsoft ABI, each base gets its own vtable, e.g. for the class C we&#39;ll \
have<br> &quot;C vtable for the A part&quot; and &quot;C vtable for the B \
part&quot;.<br> <br>
We do the same in Clang, but that&#39;d require some API changes to<br>
VTableBuilder - i.e. you&#39;ll need to know a pair of classes to generate<br>
a vtable, not just one.<br></blockquote><div><br></div><div style>It&#39;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.</div> <div style><br></div><div style>This came up in the virtual base \
table mangling patch I sent.  I assume we&#39;ll need similar logic at some \
point.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">

We can go our own Itanium-like way and emit one vtable with address<br>
points and still make this ABI-compatible (this is how my local patch<br>
works) but I have a bad feeling that this may fail to work when we<br>
start supporting virtual inheritance.<br></blockquote><div><br></div><div style>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&#39;s what we should aim for.</div> <div> \
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> Do you have any thoughts or suggestions on this?<br>
<br>
--<br>
Thanks!<br>
Timur<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" \
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br> \
</blockquote></div><br></div></div>



_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic