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

[Manuel Klimek]

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

>
> On Jul 31, 2013, at 11:15 AM, Manuel Klimek <klimek at google.com> wrote:
>
> 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.
>
>
> This makes perfect sense. Our current cross-function analysis assumes
> availability of the function implementations and we know that this approach
> definitely will not scale to cross-translation unit analysis.
>
>
> 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... ;)
>
>
> Very exciting. We'd be very interested to find out what you learn from
> this (good and bad)!
>

See the bugs Pavel is filing, and the work on making the C++ analysis
sane(r). We make pretty heavy use of C++ features. Where it finds bug it
often seems like magic ("wait, so this is called here, and then ...
ooooooooh").


> By the way, you can run the analyzer in "shallow" mode, which will turn
> off most of the interprocedural analysis and minimize the analysis time in
> other ways. This might be an option when the default analyzer mode does not
> scale.
>

Oh, single-TU analysis is not a scalability problem for us (we have
machines ;)


>
>
> Cheers,
> /Manuel
>
>
>
>>
>> Cheers,
>> Anna.
>>
>> ** **
>>
>> I wanted some feedback if this is a good idea or not.****
>> ** **
>> -Aditya****
>> _______________________________________________
>> cfe-dev mailing list
>> 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
>> 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/caedd320/attachment.html>