[llvmlinux] [GSoC] Static analysis

Behan Webster behanw at converseincode.com
Mon Apr 29 18:47:24 UTC 2013

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 
> <mailto: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.

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

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

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

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


Behan Webster
behanw at converseincode.com

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

More information about the LLVMLinux mailing list