[llvmlinux] [GSoC] Static analysis

Eduard Bachmakov e.bachmakov at gmail.com
Mon Apr 29 20:34:55 UTC 2013

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

>  On 13-04-29 02:22 PM, Eduard Bachmakov wrote:
> Hey Mark,
> On Sun, Apr 28, 2013 at 10:49 AM, Mark Charlebois <charlebm at gmail.com>wrote:
>> The build system tries to keep as much common as possible while allowing
>> you to do the following:
>>  - add new targets
>> - write common rules of targets of the same architecture
>> - write patches that are common, arch specific or target specific, or git
>> branch specific (for particular kernel versions as some targets do not
>> tract the upstream trunk)
>> - support multiple cross toolchains to validate using clang with
>> particular assemblers and linkers
>> - switching the toolchain to use with clang is as simple as changing a
>> line in the target makefile
>>  - provide easy commands to do common tasks: syncing, building at target
>> or rebuilding clang, etc
>  So if I understand this right, the system is a set of hand-written
> Makefiles (as opposed to systems like cmake or autotools)?
> Think of it more like a set of scripts used to drive Kbuild and cmake used
> by the code bases we are using. Make is the glue; IMHO neither cmake nor
> autotools are the right tools for this kind of thing.
> You can think of our build system as a test harness or a meta-build system.

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.

>    cd llvmlinux
>>  make build-dep-check
>>  -- install anything missing --
>>  cd target/vexpress
>>  make kernel-build
>  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).

>   Quick question though, why is vexpress always used as an example
> (buildbot, wiki, etc)? Is there something special about it or "just
> because"?
> It's the reference embedded ARM architecture, is well supported in QEMU,
> as well as being available as real HW. It's the go-to target for this kind
> of thing.

I see.

>    This will download LLVM and clang and build them, download the cross
>> compiler toolchains specified in the vexpress Makefile, download the
>> kernel, and then build the kernel, apply the patches to the kernel and
>> build the kernel with clang.
>>  The build system tracks all of the dependencies in state
>> subdirectories. When you clean a particular make target it will clean out
>> the files from the associated state directory.
> About the state directories: I noticed the files are empty. I assume
> you're testing for state using test -f like methods?
> The state directories are for build stamp files. Files which indicate the
> entering of a successful state of a part of the code base. It's a common
> practice in using Makefiles on large projects to speed things up.
>    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.

>   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?

>    Thanks for your interest in the project!
>  Let's hope I can help :-).
>   We would welcome your assistance!
> Behan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/llvmlinux/attachments/20130429/5bdceea2/attachment-0001.html>

More information about the LLVMLinux mailing list