[cfe-dev] Proposed: change tracking for RegionStore

[Ted Kremenek]

(Just catching up)

This is essentially what we are trying to do.  The problem is whether that map is done as a per-path property or something "global" to the instance of a Checker or GRExprEngine.  If it is per-path, the map has to go in GRState or something similar if that map isn't short-lived.  My suggestion before was that this map is essentially implicitly defined by the Checkers, since they are already tracking checker-specific state on the side.  In this case, representing this map separately in GRState seems a little silly to me, and potentially a performance concern when it comes to state caching.

On Aug 1, 2010, at 1:23 AM, Zhongxing Xu wrote:

> Are we trying to solve the problem that, some checkers want to be
> informed when some region bindings are changed?
> 
> Can we do this:
> 
> GRExprEngine maintains a RegionWatcher, which is basically a map:
>      MemRegion *  => list of Checkers who are interested in the MemRegion
> 
> Checkers first register themselves with the region they are interested
> in to the RegionWatcher.
> 
> In StoreManager::bind and other necessary places, call
> RegionWatcher::RegionChanged() with the new store and a list of
> changed regions. RegionWatcher then inform each Checker that
> registered before.
> 
> On Sat, Jul 31, 2010 at 1:42 PM, Jordy Rose <jediknil at belkadan.com> wrote:
>> 
>> On Fri, 30 Jul 2010 19:05:35 -0700, Ted Kremenek <kremenek at apple.com>
>> wrote:
>>> On Jul 30, 2010, at 3:33 PM, Jordy Rose wrote:
>>>> 
>>>> And hm. How can we inject new analysis state at the level of Bind or
>>>> Invalidate, where only the Store is being changed? Not all
>>>> store-modifying
>>>> code goes through GRState.
>>> 
>>> 
>>> I think Bind and Invalidate would still work as expected, but just
>> return
>>> the list of regions that "subscribers" had said they cared about.
>>> 
>>> Bind and Invalidate, however, are only called at specific places (e.g.,
>> in
>>> GRExprEngine), and usually when one is reasoning about a GRState or
>>> ExplodedNode.  Does it seem plausible to try and do the callbacks after
>> the
>>> Bind/Invalidate, possibly generating new ExplodedNodes?  For example, I
>> can
>>> see this happening when evaluating a store within GRExprEngine.
>> 
>> I'm thinking of modeling functions, though. The only place where this is
>> used now is MallocChecker's fill value (admittedly, a patch from me, weeks
>> ago). But memset() is basically Invalidate-then-BindDefault.
>> OSAtomicChecker is using EvalStore, but it's not as clean as it should be.
>> There's no EvalFill or EvalInvalidate. Should there be?
>> 
>> I'm inclined to not allow new ExplodedNodes here, only a one-to-one filter
>> of GRStates. That is, you can change states when getting a region update,
>> but not bifurcate the state. This limits us to "places that call
>> GRState::makeWithStore", which are a manageable set. But still not at the
>> GRExprEngine level. I'm not thrilled with turning every bind* call into
>> this:
>> 
>> RegionSet RS = C.getEngine().GetInterestingRegions();
>> tie(state, RS) = state->bindLoc(L, V, RS);
>> C.getEngine().NoteRegionsChanged(state, RS);
>> 
>> Or this:
>> 
>> state = state->bindLoc(L, V, C.getEngine());
>> 
>> They both seem like they're mixing levels. But having to move these cover
>> methods for Bind* and friends (eight methods) up to the engine seems a
>> little silly. Maybe it shouldn't.
>>