[cfe-dev] using scan-build on osx 10.9 command line

[Ted Kremenek]

> On Dec 30, 2014, at 10:12 PM, James Burgess <jamesrburgess at mac.com> wrote:
> 
>>> 
>>> Now I’d like to integrate this into my own build system. I read that if I was using make/autoconf (which I am not) I could just set CC and CXX and the right thing would happen?
>>> 
>>> I can see scan-build doing the same but most of the script seems to be about building the report html, I’m guessing I’m going to need some of that script after my build is done. Does anyone know what would be the recipe if for doing that if I had a large pile of makefiles and I’d set CC and CXX before building?
>> 
>> The "-isysroot" option points the compiler to an SDK.  Normally when you run gcc (which really is 'clang' on newer OS X installations) it is a shim to run "xcrun clang", which in turns invokes clang with the proper SDK path.  scan-build is interposing on the Makefile's compiler, and invoking clang to run static analysis.  The clang it is using, however, is the clang that came with the checker tar file, and you're not getting the automatic SDK inference that happens when you run the system clang with no SDK option.
>> 
>> When Xcode (and xcodebuild) invokes clang it always passes an explicit "-isysroot" option, which is probably why nobody using the checker builds with Xcode projects has reported a problem.
>> 
>> I think you could hack your Makefile to include an explicit "-isysroot" for OTHER_CFLAGS, but I think this is unnecessary.  You are really working around a limitation in scan-build.
>> 
>> I think one of the following two things should happen:
>> 
>> (1) ccc-analyzer (which is the fake compiler driver invoked by scan-build) should add an implicit -isysroot when running clang when no -isysroot is provided.
>> 
>> (2) We change how scan-build does interposition of the compiler during build time to use a different method that doesn't guess what the host compiler would do, but observes it directly and replicates that logic.  Right now we interpose essentially at the build system level, which doesn't get all the implicit logic that the host compiler has.
>> 
>> I've hacked up a solution for #2.  Could you try copying the attached ccc-analyzer file into the 'libexec' directory of your untarred checker directory and see if that solves the problem.
>> 
> 
> Yes that seems to work for me too. I no longer need the isysroot option. 
> 

Great.  I committed that change in r225038.

> FWIW I would be quite happy to add the -isysroot option to my build system for a static analysis build but having scan-build discern it in its absence seems ok too.
> 
> So back to my second question, like I said, I’m not using Makefiles but if I had the recipe for getting that to work I could more easily integrate this into my own build system since I’m very familiar with make. If in make all I need to do is set CC and CXX to point to the checker version of clang then I believe there’ll need to be some post process to build the html that the scan-build script does. Is that correct?
> 

You are really raising a larger question of how best to integrate the static analyzer into a build system.

It's a nuanced answer.  The idea is that we want the analyzer to see the code in the same way that the compiler does when performing a build.  Right now we're doing a poor man's interposition by overriding CC and CXX; that's essentially all scan-build does to interpose the analyzer into a (say) Makefile build.  By changing the compiler used by make, the build system invokes a fake compiler driver that invokes the real compiler and then invokes clang for doing static analysis.  Each file is separately analyzed and report files are generated.  Once the build completes, scan-build collates the HTML report files and builds an index.

There's two design points at play here that I think are worth noting:

(1) This interposition is not a great hack.  Sometimes the build system doesn't control every compiler innovation.  For example, a Makefile build could spin off a shell script that invokes the compiler, and that script may not consult CC or CXX.  Also, some Makefiles (or whatever) hardwire the compiler they use, thus setting CC or CXX has no effect.  Unless the build system has total control of the compilation jobs, the only sure way to interpose on all compiler instances is to do true OS interposition.  This can be accomplished in various platform-specific ways on different platforms, and is the approach taken by several commercial static analysis tools.

(2) The way we do analysis and gather reports could hypothetically change in the future.  Right now we analyze each file at a time, generate reports, and then stitch the reports together.  In the future, a reasonable direction for the analyzer would be do two phases of analysis: first do a pass over the files like we do now, and then do a more global analysis to find bugs that cross file boundaries.  This approach would inherently defer the generation of reports to the very end.  Also, the mechanism by which reports are generated could change.  Right now HTML files are generated eagerly, but those really are a static rendering.  A more versatile approach would be to generate output that summarizes the bug reports, and have the HTML reports (or whatever) generated from those.

Digesting it down:

(a) There's a danger of embedding too much knowledge of how the static analyzer works into the build system because the static analyzer could change in how it works or the build system may not have complete knowledge of the build process.

(b) If you want to integrate the analyzer into the build system, I'd keep the interfaces at a high level such as doing a pass over the files and doing a post-process after build.  The post-processing should possibly be done by something controlled by the static analyzer tool, not integrated into the build system.  This gives you the ability to integrate the analyzer into your build system but allow you to worry less about disruptive changes down the road.

Note that in Xcode we integrated knowledge of the analyzer into Xcode's build system.  There are distinct advantages of doing that as well: tight control of the analyzer from the build system, ease of management of resources like PCH (currently scan-build doesn't handle PCH files at all, so they are disabled), etc.  But with Xcode we are fully cognizant that the integration of the analyzer may need to change over time as the analyzer changes as well.

But back to this reasonable question:

>>  If in make all I need to do is set CC and CXX to point to the checker version of clang then I believe there’ll need to be some post process to build the html that the scan-build script does. Is that correct?

The answer is "yes" with caveats.  As I pointed out above not everything honors CC and CXX (e.g., uses an explicit compiler path), but in such cases the behavior will likely be the same as what you get with scan-build (i.e., files that aren't analyzed).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141231/02509cfa/attachment.html>