[cfe-dev] Proposed: change tracking for RegionStore
kremenek at apple.com
Mon Aug 2 19:33:43 CDT 2010
(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>
>>> 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
>>>> code goes through GRState.
>>> I think Bind and Invalidate would still work as expected, but just
>>> the list of regions that "subscribers" had said they cared about.
>>> Bind and Invalidate, however, are only called at specific places (e.g.,
>>> GRExprEngine), and usually when one is reasoning about a GRState or
>>> ExplodedNode. Does it seem plausible to try and do the callbacks after
>>> Bind/Invalidate, possibly generating new ExplodedNodes? For example, I
>>> 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
>> 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.
More information about the cfe-dev