[cfe-dev] Static Analyzer : Query regarding how symbols are marked as dead

[Karthik Bhat]

Thanks Jordan. That was useful information. I also found  *"*A memory model
for static analysis of C programs*" *by Ted also very useful.

I'm trying to implement IPA across TU for my internal project. The approach
i'm using is i'm dumping .ast of all files using -emit-ast option.
In case a function body is not found while analyzing i load the
corresponding ast file having function definition and use this FunctionDecl
with the current in-lining approach.

For example in the above code myFree()  is implemented in another file and
i get the FunctionDecl by loading the ast and use this to inline.

In this case though unfortunately region for 'q' does not contain a binding
with the symbolic value returned from malloc.

Am i doing something wrong here or missing out something?

Any inputs greatly appreciated.

Thanks

On Tue, Mar 12, 2013 at 10:09 PM, Jordan Rose <jordan_rose at apple.com> wrote:

> Hello, Karthik. The analyzer does certain deliberate passes to clean up
> dead symbols and dead bindings in the state, generally before processing
> each statement. The top-level function for this is
> ExprEngine::ExprEngine::removeDead, and most of the high-level
> implementation is in the SymbolReaper class in ProgramState.h. The basic
> algorithm is pretty simple, though:
>
> (1) Find out which expressions and variables are still live
> (LiveVariables). This is cached, per-function, context-insensitive
> information.
> (2) Ask checkers which symbols are known to be in use, though potentially
> not live (checkLiveSymbols).
> (3) Mark live any values associated with live expressions in the
> Environment. Remove all other bindings.
> (4) Mark live any values accessible via the live regions in the Store.
> Remove all other bindings.
> (5) Remove any constraints on dead symbols.
> (6) Report dead symbols to the checkers, so that they can stop tracking
> information dependent on those symbols (checkDeadSymbols).
>
>
> Your second question is easier: parameter-passing is modeled as a bind to
> the region for the parameter (a VarRegion whose associated declaration is a
> ParmVarDecl). So your myFree() example is essentially the same as this:
>
> char *q = (char *)malloc(sizeof(char);
> char *p = q;
> free(p);
> free(q); // warning
>
> This happens in the 'enterStackFrame' method on the StoreManager, which
> uses CallEvent::getInitialStackFrameContents to figure out the initial
> bindings. You are correct that both the region for 'q' and the region for
> 'p' will contain a binding with the symbolic value returned from 'malloc'.
>
> Does this help?
> Jordan
>
> P.S. For the record, this model of parameter passing will not be entirely
> correct once we model the destructors of C++ temporary regions; we will
> need to be more careful about non-POD objects being passed by value.
>
>
> On Mar 11, 2013, at 1:09 , Karthik Bhat <blitz.opensource at gmail.com>
> wrote:
>
> > Hi All,
> > I was going through Malloc checker in clang Static analyzer. I had a few
> doubts-
> >
> > 1) How is a symbol marked as dead( How does clang static analyzer detect
> that a symbol is dead) ?
> > E.g.
> >
> > char* myMalloc()
> > {
> >   char* p = (char*) malloc(sizeof(char));
> >   return p;
> > }
> >
> > int main()
> > {
> >   char* q = myMalloc();
> >   return 0;
> > }
> >
> > In the above example symbol assigned for p in myMalloc is alive till
> main(caller) exits right?
> >
> >
> > 2) In case of IPA how are symbol propagated form one function to another
> in case it is passed as a parameter.
> > E.g.
> >
> > void myFree(char* p)
> > {
> >    free(p);
> > }
> >
> > int main()
> > {
> >
> >   char* q = (char*) malloc(sizeof(char));
> >   myFree(q);
> >   free(q);
> > }
> >
> > In the above example is it true that the parameter p in myFree is
> assigned the same symbol as that of q being passed to the function? If yes
> could someone guide me were this assignment of symbol happens?
> >
> >
> > Thanks
> > Karthik
> >
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130313/ba899315/attachment.html>