[llvmlinux] [GSoC] Static analysis

Eduard Bachmakov e.bachmakov at gmail.com
Wed May 1 04:35:43 UTC 2013

On Mon, Apr 29, 2013 at 5:06 PM, Behan Webster <behanw at converseincode.com>wrote:

>  On 13-04-29 04:34 PM, Eduard Bachmakov wrote:
>  I see. Makes sense. I was just wondering if the Makefiles are generated
> automatically or written by hand. From the two responses (and the
> pretty-ness of the markup inside of them) I gather it's the latter.
> Yes, hand built. Like I said, think of it as a script.

Just wanted to make sure whether I can edit them directly (or whether they
would be overwritten at some point).

>>  I was able to x64 just fine the other day. (I also tried it with
>> allyesconfig but that (obviously) failed).
>>  We don't support all configurations yet. Getting to the point where we
>> are already has taken a lot of work already.
>  I understand. It was also on of the ideas on the GSoC page to have
> allyesconfig work. I was just curious how long until the error (longer than
> I expected; it was a VLAS).
> I would expect allyesconfig would fail very quickly. :)

Once I actually went to JOBS=1 that was indeed the case :-D.

>        As far as the scope for implementing checker for the kernel, many
>>> of the frequent contributors just have not had the time to try it. From
>>> those who have tried it, we know it doesn't just work out of the box.
>>  I see. When ever I used the analyzer it was using the scan-build tool.
>> Need to check whether it works with the custom build system
>>  We don't need to run it on our makefiles. We need it run on the kernel
>> makefiles (Kbuild). The analyzer would be driven by our build system.
>  The way I understand the system, it basically replaces env variables but
> allows customization, does error-handling, sets defaults, etc. I was just
> wondering if it would propagate through down to where the `make` that
> actually builds the kernel.
> That would be the gig: Figuring this out, then ultimately tuning it for
> the kernel if time permitted (adding specific analysis/checks which are
> Linux kernel specific).

Alright, with some experimentation I figured: it does. Well, to some extent
at least. After disabling the hardcoded CC variable in make-kernel.sh. I
was able to run the analyzer using the scan-build wrapper (ccc-analyzer).

>       Its an advanced task because the kernel make system is complcated,
>>> and it may require modifying LLVM or checker code. We just don't know yet.
>>  Alright. My plan was to read up on the whole kbuild system and see how
>> flags/commands enabling the analyzer would be integrated.
>>  The idea isn't to integrate it into the kernel build system. We want to
>> run it against the kernel build. So updates to the analyzer to support the
>> kernel would be the ideal situation.
>  I don't think I quite understand what you mean here. The analyzer itself
> is -- afaik -- the "--analyze" flag to clang (+ whatever "sub"-flags there
> are). Could you please elaborate?
> Probably my misunderstanding. Sounded like you were suggesting that it
> needed to be integrated into Kbuild. My bad.
> I was trying to clarify (unsuccessfully it seems :) ) that the tool needs
> to ideally be able to run over the Linux kernel code with a minimum of
> changes to the Kernel code itself.

I'm actually running a build right now. Let's see how far it goes (default
config, x64, JOBS=1). Will check in the morning.

I was wondering, if this ends up being part of a real GSoC project, who
would be the mentor?

Also, Behan, I circled you on G+. I'd like to attend (or watch) the meeting
on Thu if that's okay. Nothing beats face-time I guess :-).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/llvmlinux/attachments/20130501/57b856a0/attachment.html>

More information about the LLVMLinux mailing list