[llvmlinux] GSoC week 2

Andrew Wells andrewmw94 at gmail.com
Thu Jun 2 01:25:33 UTC 2016

Hi again,

Here are some updates of my work getting the clang's checker working with
the kernel.

As linked last time, I have a list of the different checkers available,
color-coded in terms of my thoughts on them.  There are several "families"
of checkers, the alpha checkers that have various issues (mostly relating
to false positives), the core checkers which are the most general purpose
ones that are stable, the unix checkers that have to do with the unix api,
malloc, strings, and other things whose handling is tied to the OS, and the
security checkers that have to do with bugs that affect the security of

I asked about these on the clang dev mailing list and got this response:

Message: 3
Date: Wed, 25 May 2016 22:39:16 +0300
From: Alexey Sidorin via cfe-dev <cfe-dev at lists.llvm.org>
To: Andrew Wells <andrewmw94 at gmail.com>, cfe-dev at lists.llvm.org
Subject: Re: [cfe-dev] LLVMLinux
Message-ID: <5745FF64.9030705 at ya.ru>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Hello Andrew,

core.StackAddressEscape - I think this checker should work for kernel well.
core.builtin.NoReturnFunctions - this service checker should decrease
the amount of FPs reported due to analyzing of unreachable paths. It may
need some tuning for kernel (adding kernel no-return functions). I vote
for enabling it.
For unix.Malloc checker we should add the support for kernel memory
allocation functions like kmalloc/kfree. The same for PthreadLock and
CString*. When it's done, they may be also enabled.
alpha.security.taint.TaintPropagation may help other checkers to find
taint-related issues. I think it should be enabled.

Accordingly, I've been looking into the checkers (specifically Malloc at
the moment) to try to understand how they work and how they can be modified
to work with the kernel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/llvmlinux/attachments/20160601/968607c1/attachment.html>

More information about the LLVMLinux mailing list