- $ TESTDIRS=Analysis make test
+ $ bin/llvm-lit -sv ../llvm/tools/clang/test/Analysis
When your command contains the -cc1 flag, you can attach the +debugger to it directly:
+ ++ $ gdb --args clang -cc1 -analyze -analyzer-checker=core test.c + $ lldb -- clang -cc1 -analyze -analyzer-checker=core test.c ++ +
+Otherwise, if your command line contains --analyze, +the actual clang instance would be run in a separate process. In +order to debug it, you'd have to either instruct your debugger to attach +itself to the child process (for example, in gcc you can +set follow-fork-mode=child), or use the -### +flag for obtaining the command line of the child process: +
+ ++ $ clang --analyze test.c -\#\#\# ++ +
+Below we describe a few useful command line arguments, all of which assume that +you are running clang -cc1. +
+ +While investigating a checker-related issue, instruct the analyzer to only
execute a single checker:
-
-$ clang -cc1 -analyze -analyzer-checker=osx.KeychainAPI test.c
-
-
+ $ clang -cc1 -analyze -analyzer-checker=osx.KeychainAPI test.c ++ +
If you are experiencing a crash, to see which function is failing while +processing a large file use the -analyzer-display-progress +option.
+ +You can analyze a particular function within the file, which is often useful +because the problem is always in a certain function:
++ $ clang -cc1 -analyze -analyzer-checker=core test.c -analyzer-display-progress + ANALYZE (Syntax): test.c foo + ANALYZE (Syntax): test.c bar + ANALYZE (Path, Inline_Regular): test.c bar + ANALYZE (Path, Inline_Regular): test.c foo + $ clang -cc1 -analyze -analyzer-checker=core test.c -analyzer-display-progress -analyze-function=foo + ANALYZE (Syntax): test.c foo + ANALYZE (Path, Inline_Regular): test.c foo ++ +
To dump the AST, which often helps understanding how the program should +behave:
++ $ clang -cc1 -ast-dump test.c ++ +
To view/dump CFG use debug.ViewCFG or debug.DumpCFG +checkers:
++ $ clang -cc1 -analyze -analyzer-checker=debug.ViewCFG test.c ++ +
ExplodedGraph (the state graph explored by the analyzer) can be +visualized with another debug checker:
++ $ clang -cc1 -analyze -analyzer-checker=debug.ViewExplodedGraph test.c ++
Or, equivalently, with -analyzer-viz-egraph-graphviz +option, which does the same thing - dumps the exploded graph in graphviz +.dot format.
+ +You can convert .dot files into other formats - in +particular, converting to .svg and viewing in your web +browser might be more comfortable than using a .dot viewer:
++ $ dot -Tsvg ExprEngine-501e2e.dot -o ExprEngine-501e2e.svg ++ +
The -trim-egraph option removes all paths except those +leading to bug reports from the exploded graph dump. This is useful +because exploded graphs are often huge and hard to navigate.
+ +Viewing ExplodedGraph is your most powerful tool for understanding +the analyzer's false positives, because it gives comprehensive information +on every decision made by the analyzer across all analysis paths.
+ +There are more debug checkers available. To see all available debug checkers: +
++ $ clang -cc1 -analyzer-checker-help | grep "debug" ++ +
To view "half-baked" ExplodedGraph while debugging, jump to a frame +that has clang::ento::ExprEngine object and execute:
++ (gdb) p ViewGraph(0) ++ +
To see the ProgramState while debugging use the following command. +
+ (gdb) p State->dump() ++ +
To see clang::Expr while debugging use the following command. If you +pass in a SourceManager object, it will also dump the corresponding line in the +source code.
++ (gdb) p E->dump() ++ +
To dump AST of a method that the current ExplodedNode belongs +to:
++ (gdb) p C.getPredecessor()->getCodeDecl().getBody()->dump() ++ +
The bug reporter mechanism removes path diagnostics inside intermediate +function calls that have returned by the time the bug was found and contain +no interesting pieces. Usually it is up to the checkers to produce more +interesting pieces by adding custom BugReporterVisitor objects. +However, you can disable path pruning while debugging with the +-analyzer-config prune-paths=false option.