<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Jul 19, 2013, at 8:33 AM, Timur Iskhodzhanov <<a href="mailto:timurrrr@google.com">timurrrr@google.com</a>> wrote:<br><div><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">2013/7/19 John McCall <<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>>:<br><blockquote type="cite">+ void LayoutVFTable() {<br>+ // FIXME: unclear what to do with RTTI in MS ABI as emitting it anywhere<br>+ // breaks the vftable layout. Just skip RTTI for now, can't mangle anyway.<br>+<br><br>Can you explain how it breaks the vftable layout? My understanding is that<br>disabling RTTI actually changes the ABI by causing the RTTI pointer to<br>be skipped in the layout, thus changing all the offsets; is it more than that?<br></blockquote><br>Please note this comment is copied from<br>VTableBuilder::LayoutPrimaryAndSecondaryVTables.<br><br>As far as I understand, if we emit RTTI, it should go to vftable[-1].<br>Otherwise there's even no slot allocated for it.<br>That means the vftable symbol should point in the middle of a section<br>(if RTTI is emitted), which is not yet supported by LLVM IIRC (see the<br>"Symbol in the middle of a global" thread).<br></div></blockquote><div><br></div><div>Ah, gotcha. Yes, having LLVM and linker support for this would be great.</div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">I think we should also use weak/strong-odr linkage for no-RTTI/RTTI<br>cases so the more complete vftables are chosen at link-time.<br></div></blockquote><div><br></div><div>I thought vf-tables never had strong linkage?</div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite">+ // See if this class expands a vftable of one of its bases.<br>+ const CXXRecordDecl *NextBase = 0, *NextLastVBase = LastVBase;<br><br>Why isn't this always just the primary base? In what situations do<br>virtual function entries ever get added to a vf-table from a non-primary<br>base?<br></blockquote><br>consider<br> struct A;<br> struct B;<br> struct C: B;<br> struct MDC: A, C;<br>if C adds new methods to B, they are put into the B's vftable.<br>Basically, each class in the hierarchy can add methods to its own<br>primary base vftable.<br></div></blockquote><div><br></div><div>Right, but from the perspective of C, they’re going in its primary vf-table</div><div>(which is the same as B-in-C’s primary vf-table).</div><div><br></div><div>This is why I was saying (1) identify tables by the most derived base</div><div>subobject for which they’re the primary vf-table and then (2) recurse</div><div>down the primary base chain from there (adding methods as you</div><div>move back towards the most derived base subobject).</div><div><br></div><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite">You have a lot of very hard-to-follow path logic in this code; it's very<br>difficult to review this without understanding the invariants better.<br></blockquote><br>I had the same complaint while reading VTableBuilder/VTableContext :)<br>That said, I'll be happy to put explaining comments into the code<br>where necessary, but it's already hard for me to decide what needs<br>more comments...<br><br><blockquote type="cite">It seems like MethodInfoMap is basically trying to track the current<br>class's notion of the final overriders of all the methods in its primary<br>vf-table?<br></blockquote><br>Not in the primary vftable but rather in the vftable it's building<br>(e.g. first vbase's votable).<br></div></blockquote><div><br></div>By "current class”, I meant the class for which you are currently adding methods.</div><div><br></div><div><blockquote type="cite" dir="auto"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Other than that - yes.<br>I think my MethodInfoMap is similar to MethodInfoMap from<br>VTableBuilder::AddMethods.<br>Please note that using FinalOverriders alone would not suffice due to<br>a different "this parameter" logic in this ABI.<br></div></blockquote><div><br></div>Right, but all that is is a mapping of methods to methods from a</div><div>different base subobject.</div><div><br></div><div>John.</div></body></html>