Ted Kremenek | ce2e332 | 2008-04-25 18:44:36 +0000 | [diff] [blame] | 1 | <html> |
| 2 | <head> |
| 3 | <title>Information on using the Static Analyzer ("LLVM Checker")</title> |
Ted Kremenek | 20c5f14 | 2008-06-11 05:26:52 +0000 | [diff] [blame] | 4 | <link type="text/css" rel="stylesheet" href="menu.css" /> |
| 5 | <link type="text/css" rel="stylesheet" href="content.css" /> |
Ted Kremenek | e0665ab | 2008-06-11 05:55:39 +0000 | [diff] [blame] | 6 | <style> |
Ted Kremenek | 482c6d4 | 2008-06-11 05:28:36 +0000 | [diff] [blame] | 7 | thead { |
| 8 | background-color:#eee; color:#666666; |
| 9 | font-weight: bold; cursor: default; |
| 10 | text-align:center; |
| 11 | border-top: 2px solid #000000; |
| 12 | border-bottom: 2px solid #000000; |
| 13 | font-weight: bold; font-family: Verdana |
| 14 | } |
| 15 | table { border: 1px #000000 solid } |
| 16 | table { border-collapse: collapse; border-spacing: 0px } |
| 17 | table { margin-left:20px; margin-top:20px; margin-bottom:20px } |
| 18 | td { border-bottom: 1px #000000 dotted } |
| 19 | td { padding:5px; padding-left:8px; padding-right:8px } |
| 20 | td { text-align:left; font-size:9pt } |
| 21 | td.View { padding-left: 10px } |
| 22 | </style> |
Ted Kremenek | ce2e332 | 2008-04-25 18:44:36 +0000 | [diff] [blame] | 23 | </head> |
| 24 | <body> |
| 25 | |
Ted Kremenek | 20c5f14 | 2008-06-11 05:26:52 +0000 | [diff] [blame] | 26 | <!--#include virtual="menu.html.incl"--> |
| 27 | |
| 28 | <div id="content"> |
| 29 | |
Ted Kremenek | 43bfbaf | 2008-06-11 06:01:28 +0000 | [diff] [blame] | 30 | <h1>Information on using the Static Analyzer</h1> |
Ted Kremenek | ce2e332 | 2008-04-25 18:44:36 +0000 | [diff] [blame] | 31 | |
Ted Kremenek | be6e516 | 2008-06-11 05:25:12 +0000 | [diff] [blame] | 32 | <p>This documents provides some notes on using the LLVM/clang static analyzer to |
| 33 | find bugs in C and Objective-C programs.</p> |
| 34 | |
| 35 | <p>Please note that this tool is <b>very early</b> in development, and there are |
| 36 | <b>many planned enhancements</b> to improve both the precision and scope of its |
| 37 | analysis algorithms as well as the kinds bugs it will find.</p> |
Ted Kremenek | ce2e332 | 2008-04-25 18:44:36 +0000 | [diff] [blame] | 38 | |
Ted Kremenek | b8a522f | 2008-06-11 16:09:34 +0000 | [diff] [blame^] | 39 | <h3>High-Level Summary</h3> |
| 40 | |
| 41 | <p>Currently the analyzer is invoked as a command-line tool. It is intended to |
| 42 | run in synchronous with a build of a project or code base. Analysis results are |
| 43 | deposited in a directory as HTML files, which can then viewed using a web |
| 44 | browser.</p> |
| 45 | |
| 46 | <p>The analyzer performs a variety of checks on code, each requiring different |
| 47 | levels of analysis precision (more precision = more CPU time). While the |
| 48 | analyzer is being designed to be as fast and light-weight as possible, please |
| 49 | <b>do not expect it to be as fast as compiling a program</b> (even with |
| 50 | optimizations enabled). Some of the algorithms needed to find bugs require in |
| 51 | the worst case exponential time. The analyzer runs in a reasonable amount of |
| 52 | time by both bounding the amount of checking work it will do as well as using |
| 53 | clever algorithms to reduce the amount of work it must do to find bugs.</p> |
| 54 | |
| 55 | <h3>Organization</h3> |
| 56 | |
| 57 | <p>This page is arranged into the following sections:</p> |
Ted Kremenek | ce2e332 | 2008-04-25 18:44:36 +0000 | [diff] [blame] | 58 | |
| 59 | <ul> |
Ted Kremenek | bd31716 | 2008-06-09 14:30:01 +0000 | [diff] [blame] | 60 | <li><a href="#Contents">Obtaining the Analyzer</a></li> |
Ted Kremenek | ce2e332 | 2008-04-25 18:44:36 +0000 | [diff] [blame] | 61 | <li><a href="#BasicUsage">Basic Usage</a></li> |
Ted Kremenek | 891a353 | 2008-04-25 20:29:37 +0000 | [diff] [blame] | 62 | <li><a href="#Output">Output of the Analyzer</a></li> |
| 63 | <li><a href="#RecommendedUsageGuidelines">Recommended Usage Guidelines</a></li> |
| 64 | <li><a href="#Debugging">Debugging the Analyzer</a> |
Ted Kremenek | ce2e332 | 2008-04-25 18:44:36 +0000 | [diff] [blame] | 65 | </ul> |
| 66 | |
Ted Kremenek | bd31716 | 2008-06-09 14:30:01 +0000 | [diff] [blame] | 67 | <h2 id="ReleaseContents">Obtaining the Analyzer</h2> |
Ted Kremenek | ce2e332 | 2008-04-25 18:44:36 +0000 | [diff] [blame] | 68 | |
Ted Kremenek | be6e516 | 2008-06-11 05:25:12 +0000 | [diff] [blame] | 69 | <p> Using the analyzer involves executing <tt>scan-build</tt> (see <a |
| 70 | href="#BasicUsage">Basic Usage</a>). <tt>scan-build</tt> will first look for a |
| 71 | <tt>clang</tt> executable in the same directory as <tt>scan-build</tt>, and then |
| 72 | search your path.</p> |
| 73 | |
| 74 | <p>If one is using the analyzer directly from the Clang sources, it suffices to |
| 75 | just directly execute <tt>scan-build</tt> in the <tt>utils</tt> directory. No |
| 76 | other special installation is needed.</p> |
| 77 | |
| 78 | <h3>Packaged Builds (currently Mac-Only)</h3> |
| 79 | |
| 80 | <p>Semi-regular builds of the analyzer on Mac OS X (10.5) are available <a |
Ted Kremenek | bd31716 | 2008-06-09 14:30:01 +0000 | [diff] [blame] | 81 | href="http://keeda.stanford.edu/~kremenek/checker">here</a>. Packaged builds for |
| 82 | other platforms may eventually be provided, but as the tool is in its early |
Ted Kremenek | be6e516 | 2008-06-11 05:25:12 +0000 | [diff] [blame] | 83 | stages we are not actively promoting releases yet. If you wish to help |
| 84 | contribute regular builds of the analyzer on other platforms, please email the |
| 85 | <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">Clang Developers' |
| 86 | mailing list</a>.</p> |
Ted Kremenek | bd31716 | 2008-06-09 14:30:01 +0000 | [diff] [blame] | 87 | |
Ted Kremenek | be6e516 | 2008-06-11 05:25:12 +0000 | [diff] [blame] | 88 | <p>Packaged builds of the analyzer expand to the following files:</p> |
Ted Kremenek | ce2e332 | 2008-04-25 18:44:36 +0000 | [diff] [blame] | 89 | |
Ted Kremenek | be6e516 | 2008-06-11 05:25:12 +0000 | [diff] [blame] | 90 | <table id="package"> |
Ted Kremenek | ce2e332 | 2008-04-25 18:44:36 +0000 | [diff] [blame] | 91 | <thead><tr><td>File</td><td>Purpose</td></tr></thead> |
| 92 | <tr><td><tt><b>scan-build</b></tt></td><td>Script for running the analyzer over a project build. <b>This is the only file you care about.</b></td></tr> |
| 93 | <tr><td><tt>ccc-analyzer</tt></td><td>GCC interceptor (called by scan-build)</td></tr> |
| 94 | <tr><td><tt>clang</tt></td><td>Static Analyzer (called by ccc-analyzer)</td><tr> |
| 95 | <tr><td><tt>sorttable.js</tt></td><td>JavaScript used for displaying error reports</td></tr> |
| 96 | </table> |
| 97 | |
Ted Kremenek | be6e516 | 2008-06-11 05:25:12 +0000 | [diff] [blame] | 98 | <h3>Other Platforms (Building the Analyzer from Source)</h3> |
| 99 | |
| 100 | <p>Packaged builds simply consist of a few files from the Clang source tree, |
| 101 | meaning that <b>anyone</b> who can build Clang can use the static analyzer. |
| 102 | Please see the <a href="get_started.html">Getting Started</a> page for more |
| 103 | details on downloading and compiling Clang.</p> |
| 104 | |
| 105 | <p>All files used by the analyzer (and included in packaged builds; <a |
| 106 | href="#package">see above</a>) other than a compiled <tt>clang</tt> executable |
| 107 | are found in the <tt>utils</tt> subdirectory in the Clang tree.</p> |
Ted Kremenek | bd31716 | 2008-06-09 14:30:01 +0000 | [diff] [blame] | 108 | |
Ted Kremenek | ce2e332 | 2008-04-25 18:44:36 +0000 | [diff] [blame] | 109 | <h2 id="BasicUsage">Basic Usage</h2> |
| 110 | |
| 111 | <p>The analyzer is executed from the command-line. To run the analyzer, you will |
| 112 | use <tt>scan-build</tt> to analyze the source files compiled by <tt>gcc</tt> |
| 113 | during a project build.</p> |
| 114 | |
| 115 | <p>For example, to analyze the files compiled under a build:</p> |
| 116 | |
| 117 | <pre> |
| 118 | $ <b>scan-build</b> make |
| 119 | $ <b>scan-build</b> xcodebuild |
| 120 | </pre> |
| 121 | |
| 122 | <p> In the first case <tt>scan-build</tt> analyzes the code of a project built |
| 123 | with <tt>make</tt>, andin the second case <tt>scan-build</tt> analyzes a project |
| 124 | built using <tt>xcodebuild</tt>. In general, the format is: </p> |
| 125 | |
| 126 | <pre> |
| 127 | $ <b>scan-build</b> <i>[scan-build options]</i> <b><command></b> <i>[command options]</i> |
| 128 | </pre> |
| 129 | |
| 130 | <p> Operationally, <tt>scan-build</tt> literally runs <command> with all of the |
| 131 | subsequent options passed to it. For example</p> |
| 132 | |
| 133 | <pre> |
| 134 | $ scan-build make <b>-j4</b> |
| 135 | </pre> |
| 136 | |
| 137 | <p>In this example, <tt>scan-build</tt> makes no effort to interpret the options |
| 138 | after the build command (in this case, <tt>make</tt>); it just passes them |
| 139 | through. In general, <tt>scan-build</tt> should support parallel builds, but |
| 140 | <b>not distributed builds</b>. Similarly, you can use <tt>scan-build</tt> to |
| 141 | analyze specific files: |
| 142 | |
| 143 | <pre> |
| 144 | $ scan-build gcc -c <b>t1.c t2.c</b> |
| 145 | </pre> |
| 146 | |
| 147 | <p> |
| 148 | This example causes the files <tt>t1.c</tt> and <tt>t2.c</tt> to be analyzed. |
| 149 | </p> |
| 150 | |
| 151 | <h3>Other Options</h3> |
| 152 | |
| 153 | <p> |
| 154 | As mentioned above, extra options can be passed to <tt>scan-build</tt>. These |
| 155 | options prefix the build command. For example:</p> |
| 156 | |
| 157 | <pre> |
| 158 | $ scan-build <b>-k -V</b> make |
| 159 | $ scan-build <b>-k -V</b> xcodebuild |
| 160 | </pre> |
| 161 | |
| 162 | <p>Here are a complete list of options:</p> |
| 163 | |
| 164 | <table> |
| 165 | <thead><tr><td>Option</td><td>Description</td></tr></thead> |
| 166 | |
Ted Kremenek | be6e516 | 2008-06-11 05:25:12 +0000 | [diff] [blame] | 167 | <tr><td><b>-a</b></td> |
| 168 | <td>The analysis to run. The default analysis is <i>checker-cfref</i>. Valid options are: <i>checker-cfref</i>, <i>fsyntax-only</i>. |
| 169 | These translate into options passed down to the <tt>clang</tt> executable, and currently this option is mainly used for debugging.</td></tr> |
| 170 | |
Ted Kremenek | ce2e332 | 2008-04-25 18:44:36 +0000 | [diff] [blame] | 171 | <tr><td><b>-o</b></td><td>Target directory for HTML report files. Subdirectories will be |
| 172 | created as needed to represent separate "runs" of the analyzer. If this option |
| 173 | is not specified, a directory is created in <tt>/tmp</tt> to store the |
| 174 | reports.</td><tr> |
| 175 | |
| 176 | <tr><td><b>-h</b><br><i><nobr>(or no arguments)</nobr></i></td><td>Display <tt>scan-build</tt> options.</td></tr> |
| 177 | |
| 178 | <tr><td><b>-k</b><br><nobr><b>--keep-going</b></nobr></td><td>Add a "keep on going" option to the |
| 179 | specified build command. <p>This option currently supports <tt>make</tt> and |
| 180 | <tt>xcodebuild</tt>.</p> <p>This is a convenience option; one can specify this |
| 181 | behavior directly using build options.</p></td></tr> |
| 182 | |
Ted Kremenek | be6e516 | 2008-06-11 05:25:12 +0000 | [diff] [blame] | 183 | <tr><td><b>-v<b></td><td>Verbose output from scan-build and the analyzer. <b>A second and third |
Ted Kremenek | ce2e332 | 2008-04-25 18:44:36 +0000 | [diff] [blame] | 184 | "-v" increases verbosity</b>, and is useful for filing bug reports against the analyzer.</td></tr> |
| 185 | |
| 186 | <tr><td><b>-V</b></td><td>View analysis results in a web browser when the build command completes.</td></tr> |
| 187 | </table> |
| 188 | |
| 189 | <p>These options can also be viewed by running <tt>scan-build</tt> with no |
| 190 | arguments:</p> |
| 191 | |
| 192 | <pre> |
| 193 | $ <b>scan-build</b> |
| 194 | |
| 195 | USAGE: scan-build [options] <build command> [build options] |
| 196 | |
| 197 | OPTIONS: |
| 198 | |
Ted Kremenek | be6e516 | 2008-06-11 05:25:12 +0000 | [diff] [blame] | 199 | -a - The analysis to run. The default is 'checker-cfref'. |
| 200 | Valid options are: 'checker-cfref', 'fsyntax-only' |
| 201 | |
Ted Kremenek | ce2e332 | 2008-04-25 18:44:36 +0000 | [diff] [blame] | 202 | -o - Target directory for HTML report files. Subdirectories |
| 203 | will be created as needed to represent separate "runs" of |
| 204 | the analyzer. If this option is not specified, a directory |
| 205 | is created in /tmp to store the reports. |
| 206 | <b>...</b> |
| 207 | </pre> |
| 208 | |
| 209 | <h2 id="Output">Output of the Analyzer</h2> |
| 210 | |
| 211 | <p> |
| 212 | The output of the analyzer is a set of HTML files, each one which represents a |
| 213 | separate bug report. A single <tt>index.html</tt> file is generated for |
| 214 | surveying all of the bugs. You can then just open <tt>index.html</tt> in a web |
| 215 | browser to view the bug reports. |
| 216 | </p> |
| 217 | |
| 218 | <p> |
| 219 | Where the HTML files are generated is specified with a <b>-o</b> option to |
Ted Kremenek | 87e795e | 2008-04-25 20:31:58 +0000 | [diff] [blame] | 220 | <tt>scan-build</tt>. If <b>-o</b> isn't specified, a directory in <tt>/tmp</tt> |
Ted Kremenek | ce2e332 | 2008-04-25 18:44:36 +0000 | [diff] [blame] | 221 | is created to store the files (<tt>scan-build</tt> will print a message telling |
| 222 | you where they are). If you want to view the reports immediately after the build |
| 223 | completes, pass <b>-V</b> to <tt>scan-build</tt>. |
| 224 | </p> |
| 225 | |
| 226 | |
Ted Kremenek | 904f100 | 2008-04-25 20:30:34 +0000 | [diff] [blame] | 227 | <h2 id="RecommendedUsageGuidelines">Recommended Usage Guidelines</h2> |
Ted Kremenek | ce2e332 | 2008-04-25 18:44:36 +0000 | [diff] [blame] | 228 | |
| 229 | Here are a few recommendations with running the analyzer: |
| 230 | |
| 231 | <h3>Always Analyze a Project in its "Debug" Configuration</h3> |
| 232 | |
| 233 | Most projects can be built in a "debug" mode that enables assertions. Assertions |
| 234 | are picked up by the static analyzer to prune infeasible paths, which in some |
| 235 | cases can greatly reduce the number of false positives (bogus error reports) |
| 236 | emitted by the tool. |
| 237 | |
| 238 | <h3>Pass -k to <tt>scan-build</tt></h3> |
| 239 | |
| 240 | <p>While <tt>ccc-analyzer</tt> invokes <tt>gcc</tt> to compile code, any |
| 241 | problems in correctly forwarding arguments to <tt>gcc</tt> may result in a build |
| 242 | failure. Passing <b>-k</b> to <tt>scan-build</tt> potentially allows you to |
| 243 | analyze other code in a project for which this problem doesn't occur.</p> |
| 244 | |
| 245 | <p> Also, it is useful to analyze a project even if not all of the source files |
| 246 | are compilable. This is great when using <tt>scan-build</tt> as part of your |
| 247 | compile-debug cycle.</p> |
| 248 | |
| 249 | <h3>Use Verbose Output when Debugging <tt>scan-build</tt></h3> |
| 250 | |
| 251 | <tt>scan-build</tt> takes a <b>-v</b> option to emit verbose output about what |
| 252 | it's doing; two <b>-v</b> options emit more information. Redirecting the output |
| 253 | of <tt>scan-build</tt> to a text file (make sure to redirect standard error) is |
| 254 | useful for filing bug reports against <tt>scan-build</tt> or the analyzer, as we |
| 255 | can see the exact options (and files) passed to the analyzer. For more |
| 256 | comprehendible logs, don't perform a parallel build. |
| 257 | |
| 258 | <h2 id="Debugging">Debugging the Analyzer</h2> |
| 259 | |
| 260 | This section provides information on debugging the analyzer, and troubleshooting |
| 261 | it when you have problems analyzing a particular project. |
| 262 | |
| 263 | <h3>How it Works</h3> |
| 264 | |
| 265 | To analyze a project, <tt>scan-build</tt> simply sets the environment variable |
| 266 | <tt>CC</tt> to the full path to <tt>ccc-analyzer</tt>. It also sets a few other |
| 267 | environment variables to communicate to <tt>ccc-analyzer</tt> where to dump HTML |
| 268 | report files. |
| 269 | |
| 270 | <p>Some Makefiles (or equivalent project files) hardcode the compiler; for such |
| 271 | projects simply overriding <tt>CC</tt> won't cause <tt>ccc-analyzer</tt> to be |
| 272 | called. This will cause the compiled code <b>to not be analyzed.</b></p> If you |
| 273 | find that your code isn't being analyzed, check to see if <tt>CC</tt> is |
| 274 | hardcoded. If this is the case, you can hardcode it instead to the <b>full |
| 275 | path</b> to <tt>ccc-analyzer</tt>.</p> |
| 276 | |
| 277 | <p>When applicable, you can also run <tt>./configure</tt> for a project through |
| 278 | <tt>scan-build</tt> so that configure sets up the location of <tt>CC</tt> based |
| 279 | on the environment passed in from <tt>scan-build</tt>: |
| 280 | |
| 281 | <pre> |
| 282 | $ scan-build <b>./configure</b> |
| 283 | </pre> |
| 284 | |
| 285 | <p><tt>scan-build</tt> has special knowledge about <tt>configure</tt>, so it in |
| 286 | most cases will not actually analyze the configure tests run by |
| 287 | <tt>configure</tt>.</p> |
| 288 | |
| 289 | <p>Under the hood, <tt>ccc-analyzer</tt> directly invokes <tt>gcc</tt> to |
| 290 | compile the actual code in addition to running the analyzer (which occurs by it |
| 291 | calling <tt>clang</tt>). <tt>ccc-analyzer</tt> tries to correctly forward all |
| 292 | the arguments over to <tt>gcc</tt>, but this may not work perfectly (please |
| 293 | report bugs of this kind). |
| 294 | |
| 295 | <h3>Filing Bugs</h3> |
| 296 | |
| 297 | We encourage users to file bug reports for any problems that they encounter. |
Ted Kremenek | be6e516 | 2008-06-11 05:25:12 +0000 | [diff] [blame] | 298 | |
| 299 | <p><b>Outside Apple</b>: Please <a |
| 300 | href="http://llvm.org/bugs/enter_bug.cgi?product=clang">file bugs</a> (against |
| 301 | Clang) in LLVM's Bugzilla database.</p> |
| 302 | |
| 303 | <p><b>Apple-internal</b>: Please file bugs in Radar against the <b>llvm - clang</b> |
| 304 | component.</p> |
| 305 | |
Ted Kremenek | 20c5f14 | 2008-06-11 05:26:52 +0000 | [diff] [blame] | 306 | </div> |
| 307 | |
Ted Kremenek | be6e516 | 2008-06-11 05:25:12 +0000 | [diff] [blame] | 308 | </body> |
| 309 | </html> |