[cfe-dev] Full program Analysis w. Clang

[Alexandros Tzannes]

Hi Anna, thank you for the link.
I had seen that recent thread. The idea of dumping summaries and merging 
those is duly noted. As well as dumping summaries and repeating the 
analysis when necessary. Wouldn't that be slow though, reading the 
source from the file-system for each pass, if you have to repeat the 
analysis many (perhaps hundreds of) times to converge? [see also 
discussion below on our analysis]

As Michael said we will use annotated code and static analysis to check 
that the annotations are correct and that the code does not have some 
types of bugs. This checking will require more from the AST than just 
the Call Graph, but will not cross TU boundaries. The next step is to 
infer these annotations (as many as possible), but that is going to be 
an expensive, iterative process that may cross TU boundaries. As I 
hinted, what creates dependencies for the inference are cycles in the 
call graph, and we would only need to merge the TUs that form cycles. 
That makes me optimistic about scalability (and also complexity) because 
it means that the problem is decomposable to a significant degree.

Cheers!
Alex

On 06/12/2012 12:12 AM, Michael Han wrote:
>
> Hi Anna,
>
> Thanks for the link.
>
> We are planning to write a static analyzer that perform analysis with 
> the aid of limited user annotations. It would be good to fit it in the 
> static analyzer infrastructure to have access to the bug reporter, 
> CFG, etc..  The missing piece for us is the whole program analysis 
> support from static analyzer (and as you pointed out, it is a big 
> project), at least from an infrastructure point of view, current 
> static analyzer is invoked per file base so each analysis won't know 
> other TU.
>
> At the beginning our analysis would be quite simple. It is not 
> flow/path sensitive at least for now and would only (Alex please 
> correct me if I am wrong..) require access to AST to construct call 
> graph. So, it looks like without accessing to all the nice features 
> done in the static analyzer we can still build the tool using 
> libTooling and AST serialization, and at the analysis time hopefully 
> we will have the whole program image ready to consume.
>
> Cheers
>
> Michael
>
> *From:*Anna Zaks [mailto:ganna at apple.com]
> *Sent:* Monday, June 11, 2012 8:34 PM
> *To:* Alexandros Tzannes
> *Cc:* cfe-dev at cs.uiuc.edu; Michael Han
> *Subject:* Re: [cfe-dev] Full program Analysis w. Clang
>
> This thread also discusses options on working with multiple TUs:
>
> http://clang-developers.42468.n3.nabble.com/C-analysis-with-Clang-td4024252.html
>
> On Jun 11, 2012, at 8:24 PM, Anna Zaks wrote:
>
>
>
> On Jun 11, 2012, at 6:23 PM, Alexandros Tzannes wrote:
>
>
> Hi all,
>
>     I am interested in using Clang to write a checker that reads in
>     custom annotations (we are considering using attributes rather
>     than pragmas) to guarantee the absence of some types of bugs. The
>     next step after this is done would be to try and infer as many of
>     the annotations as possible, but this will require whole program
>     analysis. I know that clang works per translation unit (TU), so I
>     was wondering if there is some advice on how to go about it.
>     Perhaps serialize the AST of different TUs, merge them and analyze
>     the whole program offline (after compilation) to prove the desired
>     safety guarantees.
>
>
> Are you planning to write a static analyzer checker? In general, we 
> are interested in adding whole program analyzes to the analyzer, but 
> it's an ambitious project.
>
>
> It may actually be possible to perform inference per TU, as long as 
> any cyclic call-graph dependencies are within a single TU.
>
>
> Scalability wise, developing summary based analyzes is better than 
> serializing the AST. (Very simply put, you'd analyze each function 
> separately, store their summaries, and re-analyze all the functions 
> again taking into account the generated info. If you have cyclic 
> dependencies, you could consider repeating the process more than once.)
>
>
>
> Any feedback/brainstorming will be greatly appreciated!
>
>     Cheers!
>
>     Alex
>
>     _______________________________________________
>
>     cfe-dev mailing list
>
>     cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
>
>     http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu <mailto: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/20120612/4d8dd25c/attachment.html>