<p dir="ltr">Yeah that's what I've meant - we can do RTTI later and avoid an extra dependency to make faster incremental progress</p>
<div class="gmail_quote">05.10.2012 12:15 пользователь "r4start" <<a href="mailto:r4start@gmail.com">r4start@gmail.com</a>> написал:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>On 04/10/12 23:03, Timur Iskhodzhanov
wrote:<br>
</div>
<blockquote type="cite">
<p dir="ltr">Why do you need RTTI for v*tables?<br>
I think we can start with no-RTTI</p>
</blockquote>
We can skip this step, but vf-table contains pointer to RTTI info.<br>
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.<br>
<blockquote type="cite">
<div class="gmail_quote">04.10.2012 22:31 пользователь "r4start"
<<a href="mailto:r4start@gmail.com" target="_blank">r4start@gmail.com</a>>
написал:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 04/10/2012 21:55, John McCall wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Oct 4, 2012, at 9:57 AM, r4start wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello Peter, John,<br>
<br>
As of r159090, Clang generated MSVC-incompatible
vtables.<br>
[Currently it generates the same intermediate objects
but due to<br>
r159091 they are not emitted into the object file at
all]<br>
<br>
I'd like to fix that and get MSVC-compatible vtables,
vbtables etc.<br>
<br>
Can you give some recommendations on how to achieve
that?<br>
<br>
VTableBuilder.{h,cpp} are 3K lines total which scares me
a bit :)<br>
<br>
Options:<br>
a) Duplicate a lot of code and have MSVTableComponent,
MSVTableLayout,<br>
MSVTableContext, MSVTableBuilder etc.<br>
and call different methods of different classes in
the<br>
{Itanium,Microsoft}CXXABI::EmitVTables<br>
Disadvantage: a LOT of code duplication<br>
Advantage: implementations are completely separate,
no conflicts,<br>
little chance of breaking the Itanium ABI.<br>
My opinion: don't like it.<br>
<br>
b) Inject a virtual interface at some point and provide
two<br>
implementations (Itanium, Microsoft),<br>
similar to CGCXXABI vs ItaniumCXXABI vs
MicrosoftCXXABI.<br>
If so, can you give your thoughts about which class
should be abstracted out?<br>
Unfortunately, I'm not very familiar with the code.<br>
My best guess is that VTableLayout should be
compatible with any<br>
ABI (right?) and it's the VTableContext that should be
converted into<br>
an interface.<br>
It might be that case that VTableContext is
compatible with any ABI<br>
and it's VTableBuilder that should be converted into an
interface.<br>
In any case, the current Itanium-specific parts of
the<br>
implementation should then be moved to ItaniumVTableXXX.<br>
<br>
Advantage: "the OOP way"<br>
Disadvantage: may make further progress harder if
ItaniumVTableXXX<br>
and MicrosoftVTableXX implementations are substantially
different due<br>
to different terminology/layout in the ABI.<br>
My opinion: the way to go, but the interface
injection point should<br>
be well thought of.<br>
</blockquote>
We can write some general interface - CGVTable(for
example).<br>
ItaniumVtable and MicrosoftVTable will implement this
interface.<br>
For some specific things we can do next thing:<br>
<br>
class CGVtable {<br>
// ...<br>
<br>
virtual SomeSpecificInterface *get() = 0;<br>
<br>
// ..<br>
};<br>
<br>
class MicrosoftVTable : CGVTable, SomeSpecificInterface {<br>
<br>
virtual SomeSpecificInterface *get() { return this; }<br>
<br>
};<br>
<br>
This method works fine in our code for some microsoft
specific mangling features.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
c) Add a bunch of "if (ABI == Itanium) {} else if (ABI
== Microsoft)<br>
{}" conditions to VTableBuilder.cpp<br>
It's ugly but works at least in the simple cases
(e.g. non-virtual<br>
inheritance)<br>
</blockquote>
We have working code of vf-table & vb-table generation
and we use this variant.<br>
This check will be needed only in few places.<br>
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.<br>
</blockquote>
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.<br>
<br>
<br>
</blockquote>
We do not have enough time for testing. So I can`t say that
this code fully correct it need more testing.<br>
If MS RTTI info can be committed in trunk then I can start
publish small patches with RTTI.<br>
I think after that vf-table/vb-table implementation can be
started.<br>
<br>
- Dmitry Sokolov.<br>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote></div>