[cfe-dev] Clang Static Analyzer without scan-build

[Aditya Kumar]

I have a preliminary working version of my patch and I ran it through our
test framework (>100 MLOC), and it has worked fine.

To generate the summarized report (index.html) I copied some portions of
scan-build and generated the summary.

I'm planning to write some post-processing program that parses the
report-*.html files and stores them in a database.

Will that be useful?

 

 

From: Manuel Klimek [mailto:klimek at google.com] 
Sent: Wednesday, July 31, 2013 1:15 PM
To: Anna Zaks
Cc: Aditya Kumar; clang-dev Developers; Michele Galante
Subject: Re: [cfe-dev] Clang Static Analyzer without scan-build

 

On Wed, Jul 31, 2013 at 8:07 PM, Anna Zaks <ganna at apple.com> wrote:

 

On Jul 30, 2013, at 2:37 PM, Aditya Kumar <hiraditya at codeaurora.org> wrote:





I was looking at the same problem and planning to work on it.

What I'm planning to do is having a compiler flag which enables a user to
perform compilation as well as static analysis at the same time,

and make relevant changes in the clang driver to build a set of 'Actions' in
the pipeline such that static analysis and compilation takes place
simultaneously.

This will have an overhead on the overall compilation time which is often
not the desirable thing. But there is an advantage that this flag can be
incorporated in the build-system of software.

Since the build systems are really good at tracking the files which have
changed and compiling only the minimal set of required files,

the overall turnaround time of static analysis will be very small and user
can afford to run static analyzer with every build.

 

Have you looked at how scan-build currently works? It does compile and
analyze the source files (clang is called twice). It is also driven by the
build system, so we are not reanalyzing files that the build system would
not recompile.

 

The main advantage of keeping the scan-build-like interface is that, in the
future, we plan to extend the analyzer to perform cross-file(translation
unit) analysis. This is why we encourage the use of a single entry point
(scan-build) when analyzing a project.

 

Said that, the current implementation of scan-build is hacky and could be
improved (see http://clang-analyzer.llvm.org/open_projects.html).

 

For what it's worth, I think the way to do large scale static analysis is to
run over each TU in isolation, and output all the information needed to do
the global analysis. Then, run the global analysis as a post-processing
step, after sharding the information from that first step into
parallelizable pieces.

 

Note that I'm not trying to contradict what you said :) Just wanted to throw
in some experience. We are currently starting to run the analyzer on our
internal code base (see Pavel's work) based on the Tooling/ stuff
(clang-check has grown a --analyze flag) and would be very interested in
having a system that allows full codebase analysis and still works on
~100MLOC codebases... ;)

 

Cheers,

/Manuel

 

 

 

Cheers,

Anna.





 

I wanted some feedback if this is a good idea or not.

 

-Aditya

_______________________________________________
cfe-dev mailing list
 <mailto:cfe-dev at cs.uiuc.edu> cfe-dev at cs.uiuc.edu
 <http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

 


_______________________________________________
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/20130731/42a37d7c/attachment.html>