[cfe-dev] Issue #1 from RTEMS run of clang-analyzer

[Ted Kremenek]

On Sep 24, 2010, at 6:03 AM, Joel Sherrill wrote:

>  Hi,
> 
> I guess one email with multiple issues didn't
> get attention. :( So let's try it again with
> one issue at a time.

Hi Joel,

First, sorry for not replying sooner to your earlier email.  I appreciate your efforts in trying to get scan-build to work on RTEMS.  Unfortunately, scan-build is something I can't allocate many cycles to these days, but I'll try and address some of your meta-level concerns, which will hopefully let you know whether or not to investing any more energy into trying to get it to work with RTEMS is worthwhile.  Note that scan-build is different from the static analyzer itself; scan-build is just the driver to run the static analyzer from the command line for non-Xcode projects.

As you probably inferred, scan-build is meant to have a similar interface to cov-build, which comes with Coverity Prevent.  That said, it is nowhere near that level of functionality as far as being able to transparently fit into your build.  First, cov-build does actual process interposition to intercept uses of the compiler in the build, while scan-build simply overrides the environment variable CC so that your build uses ccc-analyzer (which then in turn uses 'clang' for analysis and gcc for compilation) instead of the default compiler.  It's a total hack and is not a general solution, but it was good enough to get things basically working a couple years ago when I was just bringing up the analyzer.

When I wrote scan-build, my intention was to get some basic analysis functionality working on the Mac.  Since scan-build seemed generally useful enough that other people could try it out on other platforms, I was happy to make it publicly available and put some documentation on the clang-analyzer.llvm.org web page.  That said, it really is a hack, and has become less important on the Mac once the static analyzer could be run directly within Xcode.  Obviously it is still useful on other platforms (and even on the Mac for non-Xcode projects), but I haven't had the bandwidth for a while to do any major work on scan-build.  I also don't have the resources (both time and machines) to support getting the analyzer working on other platforms, although I fully encourage others in making that happen.

My hope was that one day, once the static analyzer had enough traction, that a community would build around improving scan-build, ideally re-writing it so that it could accomplish the following two goals:

(1) Support transparent integration into almost any build system on most platforms.

(2) Support different workflows with processing analysis results other than generating static HTML reports.

That community hasn't materialized yet; most of the open source contributors on the analyzer are mainly interested in working on the static analysis engine and checkers and not this kind of infrastructure.  Making scan-build more of a real alternative to proprietary static analysis tools (which do (1) really well) probably won't happen until someone else decides to drive it and invest some serious engineering time into doing so.

Some of the problems you have been reporting with using the analyzer on RTEMS have to do with (1), although the other issue seems to be that the Clang frontend doesn't really understand your architecture.  That means someone needs to implement the necessary driver logic, target triple support, etc., in Clang to get the analyzer working on your code.  Most of this is probably pretty minor, but it is stuff that would require modifying Clang.  I know for a fact (from my conversations with Coverity engineers) that Coverity spends a ton of resources getting their analysis tool to work on a diversity of platforms and setups, and part of that comes with adding such platform knowledge into the analysis tool itself.  So the transparency you see with using Coverity Prevent is the result of a tremendous engineering effort, interacting with customers, etc.  While Coverity has done a great job here, in comparison there is nobody driving that kind of work in scan-build at the moment.

That said, if you are interested in diving deeper, it looks like the main issues you are seeing (at least Issues #2 and #3) is that the Clang frontend doesn't understand your headers, doesn't implement some command line options, etc.  These are all issues that would be encountered if you tried using Clang as your compiler.  The static analyzer uses all the pieces of Clang just up to the part where we would do code generation in the compiler, so if the compiler would reject your code because of syntactic or similar issues then so will the static analyzer.  The next steps here is really to figure out how Clang can be taught about your platform and setup (Anton gave some pointers), but it's not something anyone else is likely to do unless they are trying to get Clang to work as an RTEMS cross compiler.

As for Issue #1, that's likely a problem in the ccc-analyzer Perl script, where it is screwing up argument processing.  I will try and took a look at that soon and see if I can figure out what is going wrong.

Anyway, I know this was a long email that didn't actually address your specific issues, but hopefully the back story will be useful for in you when assessing whether or not this is worth any more effort on your part.  The bottom line is that if you want to get scan-build working on RTEMS, it will likely require some hacking on Clang (or at least some deep investigation) on your part in order to make this happen in the near future.

Cheers,
Ted