[llvmlinux] [GSoC] Static analysis

[Behan Webster]

On 13-05-01 12:35 AM, Eduard Bachmakov wrote:
> On Mon, Apr 29, 2013 at 5:06 PM, Behan Webster 
> <behanw at converseincode.com <mailto: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).
Yes. Edit directly. We accept changes to them as patches; much like 
kernel development.

>>>
>>>         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.
LOL.

>>>             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).
Hmm. Maybe it isn't as much work as we thought? :)

>>>             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?
The mentor depends on the final work selected; both Jan-Simon and I have 
registered as mentors. For the build system related things and the 
analyzer I'm guessing it would likely be me.

> 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 :-).
We'll look forward to seeing you. Whoops. I just realized I need to send 
you the agenda. Expect an email shortly.

Behan

-- 
Behan Webster
behanw at converseincode.com

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