r192312 - Initialize vtorDisp in class constructors and destructors
Warren Hunt
whunt at google.com
Thu Oct 10 14:25:56 PDT 2013
When I run that through cl.exe with my test harness I get the following
layouts:
A : 4 : 4
0 : 00FC8144 vfp
B : 4 : 4
0 : 00FC814C vfp
C : 8 : 4
0 : 00FC815C A's vfp
4 : 00FC8154 B's vfp
D : 20 : 4
0 : 00FC8174 vfp
4 : 00FC8178 vpb
8 : 00000000 C's vtordisp (A and B don't have vtordisps)
c : 00FC816C C's (& A's) vfp
10 : 00FC8164 B's vfp
By my understanding, the offset for C is -4, A and B don't have them.
-Warren
On Thu, Oct 10, 2013 at 10:38 AM, Timur Iskhodzhanov <timurrrr at google.com>wrote:
> This one requires -8.
> We probably need to add something like getVtorDispOffset() to
> ASTRecordLayout...
> ------------------
> struct A {
> virtual void x();
> };
>
> struct B {
> virtual void f();
> };
>
> struct C : A, B {};
>
> struct D : virtual C {
> virtual void f();
> virtual ~D();
> };
>
> D d;
> ------------------
>
> 2013/10/10 Warren Hunt <whunt at google.com>:
> > In all of the tests I have run the vtorDisp is at -4.
> RecordlayoutBuilder
> > puts it there (there are weird padding rules when vtordisps are present,
> but
> > the location of a vtordisp with respect to its virtual base has always
> been
> > constant to my testing). If you have any counterexamples I would love to
> > see them!
> >
> > -Warren
> >
> >
> > On Thu, Oct 10, 2013 at 7:52 AM, Timur Iskhodzhanov <timurrrr at google.com
> >
> > wrote:
> >>
> >> 2013/10/9 Timur Iskhodzhanov <timurrrr at google.com>:
> >> > Author: timurrrr
> >> > Date: Wed Oct 9 13:16:58 2013
> >> > New Revision: 192312
> >> >
> >> > URL: http://llvm.org/viewvc/llvm-project?rev=192312&view=rev
> >> > Log:
> >> > Initialize vtorDisp in class constructors and destructors
> >> >
> >> > Reviewed at http://llvm-reviews.chandlerc.com/D1867
> >> >
> >> > ...
> >> > Modified: cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
> >> > URL:
> >> >
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp?rev=192312&r1=192311&r2=192312&view=diff
> >> >
> >> >
> ==============================================================================
> >> > --- cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp (original)
> >> > +++ cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp Wed Oct 9 13:16:58 2013
> >> > @@ -456,6 +459,61 @@ MicrosoftCXXABI::EmitCtorCompleteObjectH
> >> > return SkipVbaseCtorsBB;
> >> > }
> >> >
> >> > +void MicrosoftCXXABI::initializeHiddenVirtualInheritanceMembers(
> >> > + CodeGenFunction &CGF, const CXXRecordDecl *RD) {
> >> > + // In most cases, an override for a vbase virtual method can adjust
> >> > + // the "this" parameter by applying a constant offset.
> >> > + // However, this is not enough while a constructor or a destructor
> of
> >> > some
> >> > + // class X is being executed if all the following conditions are
> met:
> >> > + // - X has virtual bases, (1)
> >> > + // - X overrides a virtual method M of a vbase Y, (2)
> >> > + // - X itself is a vbase of the most derived class.
> >> > + //
> >> > + // If (1) and (2) are true, the vtorDisp for vbase Y is a hidden
> >> > member of X
> >> > + // which holds the extra amount of "this" adjustment we must do
> when
> >> > we use
> >> > + // the X vftables (i.e. during X ctor or dtor).
> >> > + // Outside the ctors and dtors, the values of vtorDisps are zero.
> >> > +
> >> > + const ASTRecordLayout &Layout =
> getContext().getASTRecordLayout(RD);
> >> > + typedef ASTRecordLayout::VBaseOffsetsMapTy VBOffsets;
> >> > + const VBOffsets &VBaseMap = Layout.getVBaseOffsetsMap();
> >> > + CGBuilderTy &Builder = CGF.Builder;
> >> > +
> >> > + unsigned AS =
> >> > +
> >> >
> cast<llvm::PointerType>(getThisValue(CGF)->getType())->getAddressSpace();
> >> > + llvm::Value *Int8This = 0; // Initialize lazily.
> >> > +
> >> > + for (VBOffsets::const_iterator I = VBaseMap.begin(), E =
> >> > VBaseMap.end();
> >> > + I != E; ++I) {
> >> > + if (!I->second.hasVtorDisp())
> >> > + continue;
> >> > +
> >> > + llvm::Value *VBaseOffset =
> >> > CGM.getCXXABI().GetVirtualBaseClassOffset(
> >> > + CGF, getThisValue(CGF), RD, I->first);
> >> > + // FIXME: it doesn't look right that we SExt in
> >> > GetVirtualBaseClassOffset()
> >> > + // just to Trunc back immediately.
> >> > + VBaseOffset = Builder.CreateTruncOrBitCast(VBaseOffset,
> >> > CGF.Int32Ty);
> >> > + uint64_t ConstantVBaseOffset =
> >> > + Layout.getVBaseClassOffset(I->first).getQuantity();
> >> > +
> >> > + // vtorDisp_for_vbase = vbptr[vbase_idx] - offsetof(RD, vbase).
> >> > + llvm::Value *VtorDispValue = Builder.CreateSub(
> >> > + VBaseOffset, llvm::ConstantInt::get(CGM.Int32Ty,
> >> > ConstantVBaseOffset),
> >> > + "vtordisp.value");
> >> > +
> >> > + if (!Int8This)
> >> > + Int8This = Builder.CreateBitCast(getThisValue(CGF),
> >> > + CGF.Int8Ty->getPointerTo(AS));
> >> > + llvm::Value *VtorDispPtr = Builder.CreateInBoundsGEP(Int8This,
> >> > VBaseOffset);
> >> > + // vtorDisp is always the 32-bits before the vbase in the class
> >> > layout.
> >> > + VtorDispPtr = Builder.CreateConstGEP1_32(VtorDispPtr, -4);
> >>
> >> After investigating some other tests, I'm pretty sure the "-4"
> >> vtordisp offset is not constant but rather might have a different
> >> value for more complex record layouts.
> >>
> >> Warren, do you have any insight to share on the vtordisp location in a
> >> record layout?
> >>
> >> > + VtorDispPtr = Builder.CreateBitCast(
> >> > + VtorDispPtr, CGF.Int32Ty->getPointerTo(AS), "vtordisp.ptr");
> >> > +
> >> > + Builder.CreateStore(VtorDispValue, VtorDispPtr);
> >> > + }
> >> > +}
> >> > +
> >> > void MicrosoftCXXABI::EmitCXXConstructors(const CXXConstructorDecl
> *D)
> >> > {
> >> > // There's only one constructor type in this ABI.
> >> > CGM.EmitGlobal(GlobalDecl(D, Ctor_Complete));
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131010/6f0291cb/attachment.html>
More information about the cfe-commits
mailing list