|author||Gabor Horvath <email@example.com>||Wed Feb 28 13:23:10 2018|
|committer||Gabor Horvath <firstname.lastname@example.org>||Wed Feb 28 13:23:10 2018|
[analyzer] Support for naive cross translation unit analysis The aim of this patch is to be minimal to enable incremental development of the feature on the top of the tree. This patch should be an NFC when the feature is turned off. It is turned off by default and still considered as experimental. Technical details are available in the EuroLLVM Talk: http://llvm.org/devmtg/2017-03//2017/02/20/accepted-sessions.html#7 Note that the initial prototype was done by A. Sidorin et al.: http://lists.llvm.org/pipermail/cfe-dev/2015-October/045730.html Contributions to the measurements and the new version of the code: Peter Szecsi, Zoltan Gera, Daniel Krupp, Kareem Khazem. Differential Revision: https://reviews.llvm.org/D30691 Cr-Mirrored-From: https://chromium.googlesource.com/external/github.com/llvm-mirror/clang Cr-Mirrored-Commit: 5b8b6afcd1b48d3de840874c45f7543c0d40aa64
A package designed to wrap a build so that all calls to gcc/clang are intercepted and logged into a compilation database and/or piped to the clang static analyzer. Includes intercept-build tool, which logs the build, as well as scan-build tool, which logs the build and runs the clang static analyzer on it.
Should be working on UNIX operating systems.
To run the Clang static analyzer against a project goes like this:
$ scan-build <your build command>
To generate a compilation database file goes like this:
$ intercept-build <your build command>
To run the Clang static analyzer against a project with compilation database goes like this:
--help to know more about the commands.
To run the CTU analysis, a compilation database file has to be created:
$ intercept-build <your build command>
To run the Clang Static Analyzer against a compilation database with CTU analysis enabled, execute:
$ analyze-build --ctu
For CTU analysis an additional (function-definition) collection-phase is required. For debugging purposes, it is possible to separately execute the collection and the analysis phase. By doing this, the intermediate files used for the analysis are kept on the disk in
# Collect and store the data required by the CTU analysis $ analyze-build --ctu-collect-only # Analyze using the previously collected data $ analyze-build --ctu-analyze-only
--help to get more information about the commands.
Generally speaking, the
analyze-build tools together does the same job as
scan-build does. So, you can expect the same output from this line as simple
scan-build would do:
$ intercept-build <your build command> && analyze-build
The major difference is how and when the analyzer is run. The
scan-build tool has three distinct model to run the analyzer:
Use compiler wrappers to make actions. The compiler wrappers does run the real compiler and the analyzer. This is the default behaviour, can be enforced with
Use special library to intercept compiler calls durring the build process. The analyzer run against each modules after the build finished. Use
--intercept-first flag to get this model.
Use compiler wrappers to intercept compiler calls durring the build process. The analyzer run against each modules after the build finished. Use
--override-compiler flags together to get this model.
The 1. and 3. are using compiler wrappers, which works only if the build process respects the
CXX environment variables. (Some build process can override these variable as command line parameter only. This case you need to pass the compiler wrappers manually. eg.:
intercept-build --override-compiler make CC=intercept-cc CXX=intercept-c++ all where the original build command would have been
make all only.)
The 1. runs the analyzer right after the real compilation. So, if the build process removes removes intermediate modules (generated sources) the analyzer output still kept.
The 2. and 3. generate the compilation database first, and filters out those modules which are not exists. So, it's suitable for incremental analysis durring the development.
The 2. mode is available only on FreeBSD and Linux. Where library preload is available from the dynamic loader. Not supported on OS X (unless System Integrity Protection feature is turned off).
intercept-build command uses only the 2. and 3. mode to generate the compilation database.
analyze-build does only run the analyzer against the captured compiler calls.
Because it uses
DYLD_INSERT_LIBRARIES environment variables, it does not append to it, but overrides it. So builds which are using these variables might not work. (I don't know any build tool which does that, but please let me know if you do.)
If you find a bug in this documentation or elsewhere in the program or would like to propose an improvement, please use the project's issue tracker. Please describing the bug and where you found it. If you have a suggestion how to fix it, include that as well. Patches are also welcome.
The project is licensed under University of Illinois/NCSA Open Source License. See LICENSE.TXT for details.