2009/12/17 Ted Kremenek <[email protected]>: > > On Dec 16, 2009, at 5:47 PM, Zhongxing Xu wrote: > >> 2009/12/17 Ted Kremenek <[email protected]>: >>> Hi Zhongxing, >>> >>> How do we plan on using CXXObjectRegion? >>> >>> For stack allocated objects, we will use VarRegions. For heap allocated >>> (e.g., 'new'), we will use SymbolicRegions. For fields that are C++ >>> objects we will use FieldRegions. >>> >> >> My feeling is that c++ objects may have some properties that justify >> it to be a separate region, like the vtable pointer. But apparently we >> haven't got there. > > If we wanted to represent the vtable pointer we have a variety of options, > like having something similar to FieldRegion, e.g., VTablePtrRegion, that > allows us to attach the vtable pointer as a "property" of another region. > That way a VarRegion could represent a stack allocated object, a > SymbolicRegion an objected created using 'new', etc. > >> >>> It seems that the only place where we would use CXXObjectRegions are for >>> modeling the object associated with analyzing a specific method, but I'm >>> not sure that is necessary or the right approach. ObjCObjectRegion is >>> currently only used by BasicStoreManager, and that should probably be fixed >>> so it can be removed. RegionStoreManager handles the Objective-C 'self' >>> variable by using a VarRegion for the 'self' ImplicitParamDecl, and then >>> represents the actual Objective-C object with a SymbolicRegion. There is >>> no ImplicitParamDecl for 'this', but conceptually that's what we want: a >>> way to go from CXXThisExpr to the region that represents the current >>> object. That way when we inline method calls we can simply map from >>> ("this",LocationContext) -> MemRegion*. >>> >> >> I was looking for an identity to represent the 'this' expression, but >> haven't found one, so created a new region with the type as the >> identity. > > For a given CXXThisExpr, we want to be able to map to a MemRegion > representing the current object. I don't think that requires a > CXXObjectRegion; just a way to perform that query. In other words, the > region is the value we obtain from the lookup, not the key for the lookup. > > My concern about introducing a new object region is that it doesn't add more > power to our memory model and we run into the issue of how to model > properties of objects differently for stack allocated objects and heap > allocated objects. If we perform inter-procedural analysis via inlining, for > example, the 'this' pointer could refer to a VarRegion that dwells in a > parent StackFrameContext. Alternatively, if we analyzing a C++ method in > isolation the 'this' pointer could be associated with a SymbolicRegion. > > One idea I just had is that CXXObjectRegion could serve a function similar to > the suggested VTablePtrRegion. That is, instead of CXXObjectRegion > representing the actual memory blob, it represents properties layered on that > blob. For example, we have a VarRegion or SymbolicRegion to represent the > actual object, and then have CXXObjectRegion be a subregion that associates > additional properties with that region (e.g., the vtable pointer). I'm not > certain if that is the right approach if we want to allow rich modeling of > downcasts, as the specific type of an object referred to by a pointer might > not be known, but we might have constraints on that object (e.g., it > subclasses class A). This seems difficult to model with a region that > associates a specific type with an object. > >
I admit that CXXObjectRegion does not make much sense for now. I'll try to replace it with a symbolic region, that seems the only viable alternative. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
