llvm-project/clang/tools/scan-build-py
Devin Coughlin 80e74cdc68 [scan-build-py] Increase precision of timestamp in report directory name
This commit improves compatibility with the perl version of scan-build.

The perl version of scan-build produces output report directories with
increasing lexicographic ordering. This ordering is relied on by the CmpRuns.py
tool in utils/analyzer when comparing results for build commands with multiple
steps. That tool tries to line up the output directory for each step between
different runs of the analyzer based on the increasing directory name.

The python version of scan-build uses file.mkdtemp() with a time stamp
prefix to create report directories. The timestamp has a 1-second precision.
This means that when analysis of a single build step takes less than a second
the ordering property that CmpRuns.py expects will sometimes not hold,
depending on the timing and the random suffix generated by mkdtemp(). Ultimately
this causes CmpRuns to incorrectly correlate results from build steps and report
spurious differences between runs.

This commit increases the precision of the timestamp used in scan-build-py to
the microsecond level. This approach still has the same underlying issue -- but
in practice analysis of any build step is unlikely to take less than a
millisecond.

Differential Revision: https://reviews.llvm.org/D24163

llvm-svn: 280768
2016-09-06 23:42:51 +00:00
..
bin [analyzer] Fix execution permissions for the scan-build-py scripts. 2016-08-01 10:55:59 +00:00
libear
libscanbuild [scan-build-py] Increase precision of timestamp in report directory name 2016-09-06 23:42:51 +00:00
tests [scan-build-py] Increase precision of timestamp in report directory name 2016-09-06 23:42:51 +00:00
README.md

README.md

scan-build

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.

Portability

Should be working on UNIX operating systems.

  • It has been tested on FreeBSD, GNU/Linux and OS X.
  • Prepared to work on windows, but need help to make it.

Prerequisites

  1. python interpreter (version 2.7, 3.2, 3.3, 3.4, 3.5).

How to use

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:

$ analyze-build

Use --help to know more about the commands.

Limitations

Generally speaking, the intercept-build and 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:

  1. 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 --override-compiler flag.

  2. 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.

  3. Use compiler wrappers to intercept compiler calls durring the build process. The analyzer run against each modules after the build finished. Use --intercept-first and --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 CC and 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.

Known problems

Because it uses LD_PRELOAD or 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.)

Problem reports

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.

License

The project is licensed under University of Illinois/NCSA Open Source License. See LICENSE.TXT for details.