Hi, I’m a student in GSoC working on the LLVMLinux project trying to get the Clang static analyzer working with the kernel. I’m in the process of sorting through which checkers are or are not applicable to the kernel. I was wondering if anyone could give me a run-down on the state of the alpha checkers, ie. what issues they have for this project. Also I have a list of checkers color-coded by which ones are applicable to the kernel. If you have some free-time and want to save me some headache would you mind pointing out any obvious mistakes with the list. https://docs.google.com/spreadsheets/d/1wt1hNl1tqY8XjSZmZCydfa2yZqKXDSvDT0uVxDutRHA/edit#gid=0

Thanks for the help.

–Andrew Wells

I’ve run the static analyzer on bare metal code, including the underlying OS. I left all the default checkers on and everything was fine. The main thing that was missing was the annotation for the various assert-like macros.

I would recommend leaving the default checkers on unless you run into a specific problem. Sure, things like the NewDelete checker will still get “run”, but they won’t really trigger on anything in the Linux kernel.

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.

25.05.2016 21:47, Andrew Wells via cfe-dev пишет: