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" <[email protected]> написал:
> On Jul 26, 2013, at 11:04 AM, Timur Iskhodzhanov <[email protected]> > wrote: > > 2013/7/25 John McCall <[email protected]>: > > On Jul 25, 2013, at 10:20 AM, Timur Iskhodzhanov <[email protected]> > wrote: > > 2013/7/25 John McCall <[email protected]>: > > On Jul 22, 2013, at 6:11 AM, Timur Iskhodzhanov <[email protected]> > 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. >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
