[PATCH] Add MicrosoftVFTableContext to AST

[Timur Iskhodzhanov]

OK.
On my way home I realized changing ComputeThisOffset should be much much
more trivial than I've tried and now I agree the anticipated version of the
code should be much more straightforward to understand.
26 июля 2013 г. 22:12 пользователь "John McCall" <rjmccall at gmail.com>
написал:

> On Jul 26, 2013, at 11:04 AM, Timur Iskhodzhanov <timurrrr at google.com>
> wrote:
>
> 2013/7/25 John McCall <rjmccall at gmail.com>:
>
> On Jul 25, 2013, at 10:20 AM, Timur Iskhodzhanov <timurrrr at google.com>
> wrote:
>
> 2013/7/25 John McCall <rjmccall at gmail.com>:
>
> On Jul 22, 2013, at 6:11 AM, Timur Iskhodzhanov <timurrrr at google.com>
> wrote:
>
> +// The main differences are:
> +//  1. Separate vftable and vbtable.
> +//  2. Each non-primary base class that has new virtual methods gets its
> +//     own vfptr and vftable, all the address points are zero.
>
> This is not a difference.
>
>
> As far as I understand, in Itanium ABI each subobject that adds new
> virtual methods to its bases gets a new *address point* in the shared
> vtable, but not a new vtable (at least no new sections are generated),
> which IS different from the Microsoft ABI.
>
>
> I’m not sure what it means for a subobject to "add virtual methods to its
> bases”.
>
>
> Rephrased to:
> //  2. Each subobject with a vfptr gets its own vftable rather than an
> address
> //     point in a single vtable shared between all the subobjects.
>
> Does this make sense now?
>
>
> Oh, yes, good point..  That fact that distinct vf-tables are allocated as
> separate symbols is an excellent thing to mention.
>
> In both ABIs, the algorithm for performing a virtual function call is to
> adjust
> the base pointer to a subobject which contains the method in its primary
> v-table, load a function pointer from the v-table, and call it.
>
> In your example, the difference is just that, under MSVC, B doesn’t have
> an entry for f() in its vf-table.  (In fact, it doesn’t have a vf-table.)
> So the
> caller has to adjust to something that actually does have an entry for f(),
> namely A.
>
> +  // See if this class expands a vftable of the base we look at, which is
> either
> +  // the one defined by the vfptr base path or the primary base.
>
> Still not sure why you’re not just starting from the right base and then
> walking up the primary base chain.
>
>
> That's not enough even in the simple case of "B: A".
>
> The vfptr is in the A layout, so the "right base" is A.
> If we don't go to the most derived class (B) from "the right base"
> (A), we forget to add the more derived class's own new methods (and
> probably return-adjusting thunks).
>
>
> My point is that you should just start recursing from B instead of this
> weird
> combination of walking the path and then falling back on climbing the
> primary base chain.
>
> Finding B (the most-derived subobject that A is in the primary-base chain
> of)
> should be really easy — it’s just a depth-first search through the complete
> object’s layout, stopping at the first thing with the same offset as A.
>
>
> Hm...
>
> Let's consider
> --------
>  struct A {
>    virtual TYPE* f();
>  };
>  struct B {
>    virtual TYPE* g();
>  };
>  struct C: A, B {  <something>  }
> --------
> We'll have two vfptrs: for A at offset 0 and for B at offset 4
> (assuming 32-bit arch).
>
> Currently, for the B's vftable we'll do this:
>  enter AddMethods(C)
>    enter AddMethods(B)
>    allocate a vftable slot for B::g
>    leave AddMethods(B)
>  update the B::g slot with this/return adjustment if C overrides it
>  leave AddMethods(C)
> [this somewhat reflects how Itanium's VTableContext works]
>
> Basically what you want is
>  enter AddMethods(B)
>  allocate a vftable slot for B::g,
>    if we have a (final) overrider for g() in C,
>      calculate this/return adjustment right here*.
>  leave AddMethods(B)
>
> Ok, so at the (*) stage we can probably find the FinalOverrider to
> just write the adjustments immediately...
> This implies rewriting ComputeThisOffset to just take the final
> overrider and return the this offset in a complete object.
> There were a few minor complexities in rewriting it (e.g. API being
> not convenient) that have overloaded my brain on Friday evening
> though.
>
> Do you think this is important for the first version? If so - I'll
> continue trying to do this next week.
>
>
> I think it’s worth it, thanks.
>
> I’ll wait to review that unless there’s something intermediate about
> the current patch you’d like me to check out.
>
> John.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130726/54447dc2/attachment.html>