using scan-build on osx 10.9 command line

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

using scan-build on osx 10.9 command line

James Burgess-2
Hi,
 I’m having trouble getting going with scan-build. I downloaded checker-276 from the link on http://clang-analyzer.llvm.org and I can’t get the simplest example to run. The first error is the clang in checker-276 is that it can’t find a system header (stdio.h in my case). I have Xcode 6.0.1 installed and gcc and g++ work fine from the command line:

 jrb$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix

If I use a very simple example:
jrb$ cat main.c
#include <stdio.h>
int
main(int argc, char** argv)
{
    printf("hello world\n");
    return 0;
}

When I run scan-build I get this:

jrb$ ~/Downloads/checker-276/scan-build gcc -g main.c
scan-build: Using '/Users/jrb/Downloads/checker-276/bin/clang' for static analysis
main.c:1:10: fatal error: 'stdio.h' file not found
#include <stdio.h>
         ^
1 error generated.
main.c:1:10: fatal error: 'stdio.h' file not found
#include <stdio.h>
         ^
1 error generated.
scan-build: 0 bugs found.
scan-build: The analyzer encountered problems on some source files.
scan-build: Preprocessed versions of these sources were deposited in '/var/folders/cd/pbxz31kj4bl_x_t1dzxnqxhm0000gn/T/scan-build-2014-12-20-221956-7628-1/failures'.
scan-build: Please consider submitting a bug report using these files:
scan-build:   http://clang-analyzer.llvm.org/filing_bugs.html


- James


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: using scan-build on osx 10.9 command line

Ted Kremenek
Hi James,

I just tried replicating your problem and was unable to do so.

A couple questions:

(1) If you just run "gcc -g main.c" can the compiler successfully compiler main.c?  I'm assuming the answer is "yes", but it is a good sanity check.

(2) Does it work if you pass an explicit SDK path?

For example:

scan-build gcc -g main.c -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk

Cheers,
Ted


> On Dec 20, 2014, at 10:35 PM, James Burgess <[hidden email]> wrote:
>
> Hi,
> I’m having trouble getting going with scan-build. I downloaded checker-276 from the link on http://clang-analyzer.llvm.org and I can’t get the simplest example to run. The first error is the clang in checker-276 is that it can’t find a system header (stdio.h in my case). I have Xcode 6.0.1 installed and gcc and g++ work fine from the command line:
>
> jrb$ gcc --version
> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1
> Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
> Target: x86_64-apple-darwin13.4.0
> Thread model: posix
>
> If I use a very simple example:
> jrb$ cat main.c
> #include <stdio.h>
> int
> main(int argc, char** argv)
> {
>   printf("hello world\n");
>   return 0;
> }
>
> When I run scan-build I get this:
>
> jrb$ ~/Downloads/checker-276/scan-build gcc -g main.c
> scan-build: Using '/Users/jrb/Downloads/checker-276/bin/clang' for static analysis
> main.c:1:10: fatal error: 'stdio.h' file not found
> #include <stdio.h>
>        ^
> 1 error generated.
> main.c:1:10: fatal error: 'stdio.h' file not found
> #include <stdio.h>
>        ^
> 1 error generated.
> scan-build: 0 bugs found.
> scan-build: The analyzer encountered problems on some source files.
> scan-build: Preprocessed versions of these sources were deposited in '/var/folders/cd/pbxz31kj4bl_x_t1dzxnqxhm0000gn/T/scan-build-2014-12-20-221956-7628-1/failures'.
> scan-build: Please consider submitting a bug report using these files:
> scan-build:   http://clang-analyzer.llvm.org/filing_bugs.html
>
>
> - James
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: using scan-build on osx 10.9 command line

James Burgess
Hi Ted,
 Thanks for the reply

(1) Yes, I can compile normally with gcc/g++. I use the command line tools for building a pretty sizable code base that is mostly c++. This is a very stock Mac, it had 10.9 when I tried this the first time but I’ve now updated to 10.10.1 and I get the same error. After upgrading to 10.10 I ran Xcode to see if it wanted to update, it did install something but it looks like the gcc/g++ report the same versions with a slight bump in the build number (clang-600.0.56)

2) using -isysroot fixes the problem, success!

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?

Cheers,
 - James


> On Dec 29, 2014, at 10:37 PM, Ted Kremenek <[hidden email]> wrote:
>
> Hi James,
>
> I just tried replicating your problem and was unable to do so.
>
> A couple questions:
>
> (1) If you just run "gcc -g main.c" can the compiler successfully compiler main.c?  I'm assuming the answer is "yes", but it is a good sanity check.
>
> (2) Does it work if you pass an explicit SDK path?
>
> For example:
>
> scan-build gcc -g main.c -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
>
> Cheers,
> Ted
>
>
>> On Dec 20, 2014, at 10:35 PM, James Burgess <[hidden email]> wrote:
>>
>> Hi,
>> I’m having trouble getting going with scan-build. I downloaded checker-276 from the link on http://clang-analyzer.llvm.org and I can’t get the simplest example to run. The first error is the clang in checker-276 is that it can’t find a system header (stdio.h in my case). I have Xcode 6.0.1 installed and gcc and g++ work fine from the command line:
>>
>> jrb$ gcc --version
>> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1
>> Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
>> Target: x86_64-apple-darwin13.4.0
>> Thread model: posix
>>
>> If I use a very simple example:
>> jrb$ cat main.c
>> #include <stdio.h>
>> int
>> main(int argc, char** argv)
>> {
>>  printf("hello world\n");
>>  return 0;
>> }
>>
>> When I run scan-build I get this:
>>
>> jrb$ ~/Downloads/checker-276/scan-build gcc -g main.c
>> scan-build: Using '/Users/jrb/Downloads/checker-276/bin/clang' for static analysis
>> main.c:1:10: fatal error: 'stdio.h' file not found
>> #include <stdio.h>
>>       ^
>> 1 error generated.
>> main.c:1:10: fatal error: 'stdio.h' file not found
>> #include <stdio.h>
>>       ^
>> 1 error generated.
>> scan-build: 0 bugs found.
>> scan-build: The analyzer encountered problems on some source files.
>> scan-build: Preprocessed versions of these sources were deposited in '/var/folders/cd/pbxz31kj4bl_x_t1dzxnqxhm0000gn/T/scan-build-2014-12-20-221956-7628-1/failures'.
>> scan-build: Please consider submitting a bug report using these files:
>> scan-build:   http://clang-analyzer.llvm.org/filing_bugs.html
>>
>>
>> - James
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: using scan-build on osx 10.9 command line

Ted Kremenek

On Dec 30, 2014, at 12:41 PM, James Burgess <[hidden email]> wrote:

Hi Ted,
Thanks for the reply

(1) Yes, I can compile normally with gcc/g++. I use the command line tools for building a pretty sizable code base that is mostly c++. This is a very stock Mac, it had 10.9 when I tried this the first time but I’ve now updated to 10.10.1 and I get the same error. After upgrading to 10.10 I ran Xcode to see if it wanted to update, it did install something but it looks like the gcc/g++ report the same versions with a slight bump in the build number (clang-600.0.56)

Ok, this is what I thought.


2) using -isysroot fixes the problem, success!

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.



Full disclosure:

$ git diff
diff --git a/tools/scan-build/ccc-analyzer b/tools/scan-build/ccc-analyzer
index 4c8f648..c993282 100755
--- a/tools/scan-build/ccc-analyzer
+++ b/tools/scan-build/ccc-analyzer
@@ -41,10 +41,14 @@ my $Clang;
 my $DefaultCCompiler;
 my $DefaultCXXCompiler;
 my $IsCXX;
+my $UseXCRUN = 0;

 if (`uname -a` =~ m/Darwin/) {
   $DefaultCCompiler = 'clang';
   $DefaultCXXCompiler = 'clang++';
+  if (-x "/usr/bin/xcrun") {
+    $UseXCRUN = 1;
+  }
 } else {
   $DefaultCCompiler = 'gcc';
   $DefaultCXXCompiler = 'g++';
@@ -478,6 +482,7 @@ my $HtmlDir = $ENV{'CCC_ANALYZER_HTML'};
 my %DisabledArchs = ('ppc' => 1, 'ppc64' => 1);
 my %ArchsSeen;
 my $HadArch = 0;
+my $HasSDK = 0;

 # Process the arguments.
 foreach (my $i = 0; $i < scalar(@ARGV); ++$i) {
@@ -500,6 +505,12 @@ foreach (my $i = 0; $i < scalar(@ARGV); ++$i) {
     next;
   }

+  # On OSX/iOS, record if an SDK path was specified.  This
+  # is innocuous for other platforms, so the check just happens.
+  if ($Arg =~ /^-isysroot/) {
+    $HasSDK = 1;
+  }
+
   # Options with possible arguments that should pass through to compiler.
   if (defined $CompileOptionMap{$ArgKey}) {
     my $Cnt = $CompileOptionMap{$ArgKey};
@@ -644,6 +655,15 @@ foreach (my $i = 0; $i < scalar(@ARGV); ++$i) {
   }
 }

+# If we are on OSX and have an installation where the
+# default SDK is inferred by xcrun use xcrun to infer
+# the SDK.
+if (not $HasSDK and $UseXCRUN) {
+  my $sdk = `/usr/bin/xcrun --show-sdk-path -sdk macosx`;
+  chomp $sdk;
+  push @CompileOpts, "-isysroot", $sdk;
+}
+
 if ($Action eq 'compile' or $Action eq 'link') {
   my @Archs = keys %ArchsSeen;
   # Skip the file if we don't support the architectures specified.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

ccc-analyzer (19K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: using scan-build on osx 10.9 command line

James Burgess

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. 

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?

Regards,
- James
 



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: using scan-build on osx 10.9 command line

Ted Kremenek

On Dec 30, 2014, at 10:12 PM, James Burgess <[hidden email]> 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).

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: using scan-build on osx 10.9 command line

James Burgess
Thanks Ted for your insight, should be fairly straightforward for me now.

On Dec 31, 2014, at 12:01 AM, Ted Kremenek <[hidden email]> wrote: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.

This might be irrelevant but I have spent a *lot* of time wrestling makefile-based systems over the years (~25 years) both my own and others. I personally would consider a Makefile that hardwires CC or CXX to be a broken Makefile. I would not let that influence my thinking on how I’d implement the analyzer. The business of running another script from a Makefile is one of the reasons I'm not using make anymore, while sometimes necessary it just a path that leads to a rats nest and so I would also disregard that when thinking about making an analyzer.



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


A two phase system sounds like a huge win if it gets global analysis. As far as the interface between the build system and the analyzer goes, for this I would think it will come down to how to pass the state from each phase. You could require the build system pass in some identifier to the analyzer for each pass. The identifier could then be turned into a directory name or db key to do whatever it needed to communicate between passes. Feels like a natural thing for a build system to do (generate a build id). I’m sure when I go look in the scan-build script there’s going to be some “look in /tmp for a set of files named X” type arrangement, this would just be formalizing that idea. 

Thanks again for your help,

- James


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: using scan-build on osx 10.9 command line

Ted Kremenek

On Dec 31, 2014, at 11:21 AM, James Burgess <[hidden email]> wrote:

Thanks Ted for your insight, should be fairly straightforward for me now.

On Dec 31, 2014, at 12:01 AM, Ted Kremenek <[hidden email]> wrote: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.

This might be irrelevant but I have spent a *lot* of time wrestling makefile-based systems over the years (~25 years) both my own and others. I personally would consider a Makefile that hardwires CC or CXX to be a broken Makefile. I would not let that influence my thinking on how I’d implement the analyzer. The business of running another script from a Makefile is one of the reasons I'm not using make anymore, while sometimes necessary it just a path that leads to a rats nest and so I would also disregard that when thinking about making an analyzer.

I have similar sentiments about having well-structured Makefiles/build systems.  That said, if a goal for the analyzer is to be relatively turn key for any build system then the analyzer needs to be able to work without making any assumptions on how the build system is implemented.  Thus the build system becomes a black box, and a mixture of Makefiles and scripts aggregates into just something that performs a build.  If it is not CC or CXX, perhaps some other piece of information acts as the locus to tie a combination of Makefiles or scripts together?  Even for well-principled builds, there is enough variation with how people do things that I have found that without deep integration of the analyzer with the build system there's really no assumptions one can make on how the build system works.

That said, I think deep integration of the analyzer in a build system, as we have done with Xcode/xcodebuild, is extremely powerful, and enables new workflows and encourages people to have well-structured projects that are amendable to great tooling.




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


A two phase system sounds like a huge win if it gets global analysis. As far as the interface between the build system and the analyzer goes, for this I would think it will come down to how to pass the state from each phase. You could require the build system pass in some identifier to the analyzer for each pass. The identifier could then be turned into a directory name or db key to do whatever it needed to communicate between passes. Feels like a natural thing for a build system to do (generate a build id). I’m sure when I go look in the scan-build script there’s going to be some “look in /tmp for a set of files named X” type arrangement, this would just be formalizing that idea. 

A two phase approach technically doesn't even require the build system to get involved.  The analyzer can interpose on the build, intercepting uses of the compiler, and do the first phase.  That interposition can dump results anywhere without needing to thread phase state into the build system.  Indeed, the second phase can happen completely asynchronously from the build itself, delayed much later or even run on a different machine.  I've seen some static analysis tools take this approach, which allows them to integrate within a large nightly build and delay the expensive static analysis part until after the build completes.

If this was integrated into the build system, I think the build system would just need to know where the dump the phase 1 stuff and inform the analyzer of this information.  The build system could then be responsible for running the phase 2 (post-build), or something else could be responsible for initiating that part.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev