[cfe-dev] checkers: decoupling ValueManager from GRStateManager

[Olaf Krzikalla]

Am 26.10.2010 18:52, schrieb Ted Kremenek:
> I think it might be easier for me to see where this is going if I had an
> idea of what you *don't* want to use.
Maybe that's indeed the right question. To start again: my only goal is 
to know if two expressions refer to the same memory location (with 
former assignments taken into consideration). The memory location is 
represented by a MemRegion and my reasoning engine is already based on 
SVals. However I reason over basic blocks only (only parts of a 
function) and I want to control which statements are analyzed.
Of course my reasoning holds an internal state too, which holds the 
binding of SVals to MemRegions. That said, I have no problem with 
GRState as it is. Indeed, this and StoreManager provides some 
functionality which I currently have implemented by my own (but like to 
get rid off).
A fundamental difference is that I actually have only one state (which 
changes or gets extended when a new assignment is evaluated). Thus I 
don't need all the ExplodedNode stuff of GRExprEngine.
Another difference is the overall purpose of my analysis: it is not for 
bug reporting, but for code optimization. Thus I don't need the 
diagnostic part of AnalysisManager.
Unfortunately it is currently not possible to use only some parts of the 
GR framework. If you stick on GRState, you need GRStateManager, which in 
turn needs GRSubEngine, which eventually needs an AnalysisManager, which 
I don't want to use in its current form.
In addition, I initially thought that I can control the generation of 
ExplodedNodes in GRExprEngine so, that there is always only one 
successor node representing the actual state. But that attempt failed 
too. Thus I have mentally abandoned the GR* framework.
However I still have hope that I can use other parts like the building 
of SVals from binary expressions as it is done in SValuator.
Maybe I should just left the triumvirate of ValueManager, SValuator and 
StoreManager to your disposal and just introduce an abstraction layer 
for GRState. A very quick check shows, that the only functions of 
GRState used by StoreManager and SValuator are getStore, getSymVal and 
getSVal. Introducing an ABC as base class of GRState
could decouple the three classes (and their subclasses) from the 
GREngine (and ConstraintManager too). Of course I could go even one step 
higher and try to decouple GRStateManager from GRSubEngine (or change 
GRSubEngine).
The bottom line is that I actually have no idea where I can or shall 
make the cut between the actual GR framework and the underlying helper 
classes. You claim that it is all tightly coupled.

 > Currently GRState* is passed to SValuator because
> SimpleSValuator uses methods from ConstraintManager (which it can
> reference via a GRState object).
I wouldn't go so far to say that SValuator uses ConstraintManager. It 
just uses 'any' method to retrieve the integer value of a symbol.

> In particular,
> SimpleSValuator uses ConstraintManager::getSymVal(), which is a virtual
> method whose result depends on the current GRState. Thus I'm not really
> certain this dependency can be severed unless we sever the dependency
> between SValuator and ConstraintManager.
But I don't see why it is bad to sever this dependency?

 > Nobody else aside
> from you has expressed interest in reusing these components in a
> different context, so you will probably need to drive this work.
Several month ago someone asked about taint analysis, subject was "Help 
with Taint analysis".

> since it seems you are interested in using both SValuator and the
> StoreManager
Indeed.

 > (which inherently rely on a bunch of other stuff).
And that's what I want to change.


Best regards
Olaf Krzikalla