[llvmlinux] [GSoC] Integrating the Clang static analyzer: first (rough) proposal draft
Jan-Simon Möller
dl9pf at gmx.de
Thu May 2 20:38:02 UTC 2013
Hi Eduard,
Fine my first-glance comments inline. I'll sleep over it and reply in the
morning.
On Thursday 02 May 2013 14:51:22 Eduard Bachmakov wrote:
> This is my first write-up. This would be part of "My Project" in the actual
> proposal. The schedule will follow once the scope is a bit more pinned down.
>
> Questions/comments/concerns?
>
> Why bother?
> =========
> Static analysis detects semantic errors which are usually hard to find:
> either some test fails or the issue appears under specific conditions no
> test was designed for. Or, even worse, there is no crash but a subtle issue
> like garbage values. Implementing static analysis allows skipping much of
> the debugging involved and fix the issue right away or at least think
> through why the analyzer would return a false-positive, saving time and
> sleep.
Why bother for the linux kernel (and thus android ;) ) ?
> clang-analyzer (checker) is one such static analyzer and fits nicely within
> the llvmlinux project.
Good. We can use and demonstrate the powers of llvm/clang/checker.
> What?
> =====
> In order to get a pleasurable developer experience, multiple steps are
> necessary:
>
> - Integrating checker into the build system
> - Simple checks are already easy to do by stetting $C and $CHECK
> variables. However, most of the time more context than offending line
> is necessary (e.g. null pointer dereference), which is why `scan-build`
> provides much of the necessary context.
> - Using `scan-build` within the build system is non-trivial.
> Integration of a target, e.g. `make analysis` would be the first goal
Yes, the visual output is the goal here .
> - Integration with buildbot
> - Instead of capturing simple stdio, the idea is to extend the
> buildbot associate each build with the relevant analysis report. This
> way would e.g. allow interested kernel developer who do not want to go
> through
> the trouble of setting up their own build system see any/all issues
> with their code (per target)
Reports for checker and also a report on "what error/warning happend how
often" are useful.
> - Choosing relevant existing checks
> - checker already has a sizable list of available checks,
> http://clang-analyzer.llvm.org/available_checks.html , and not all
> are relevant for linux. The goal is to find a reasonable default
> - Modifying existing checks
> - Some of the checks don't necessarily work as intended. "Undefined
> or garbage value returned to caller" is disctracting if the variable
> was created using a macro that explicitly states so.
> - Add new checks
> - The existing checks are by no means exhaustive. With a project as
> big as linux, there should be plenty of bugs available to derive
> new checks
> from. [I know this is handwavy, hoping for input]
- sparse is a start (replicate functionality, extend functionality)
> - Create aggregate statistics tool
> - What goes wrong most?
> - Who's code is breaking (... checker)?
> - etc.
> - What else?
> - @LLVMLINUX folks, what would you like to see happen?
More on that after some sleep.
>
> When/How?
> =========
> TBD.
scan-build, visual output of buildbot until mid-term ?
extensions, new checks, possible stand-alone tool finally ?
First shot...
Best,
JS
More information about the LLVMLinux
mailing list