On Jul 30, 2010, at 3:33 PM, Jordy Rose wrote:
>> One thing I like about this approach is that it could be a natural
>> extension of the Checker callback interface.
>> If that's the case, what's the best way for checkers to register their
> interest in a region? Do they register with the GRExprEngine, the
> GRStateManager, or directly with the StoreManager?
Interest in a region is probably something that would go into GRState, but that "registration" of interest can be implicit. For example, GRExprEngine could query the checkers for the set of "interesting" regions given a GRState*. After all, a given checker probably knows what regions it cares about because it is already tracking checker-specific state for them.
>> 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.