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.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
