[llvmlinux] GSoC project ideas brainstorm

Behan Webster behanw at converseincode.com
Tue Mar 19 19:08:50 UTC 2013

On 03/19/13 10:29, Jan-Simon Möller wrote:
> Hi all!
> Find my comments (after having slept over it ;) ) inline ... 
> Am Montag, 18. März 2013, 22:35:31 schrieb Tinti:
>> On Mon, Mar 18, 2013 at 2:20 PM, Jan-Simon Möller <dl9pf at gmx.de> wrote:
>>> Hi all!
>>> I'd like to start a brainstorm session on topics for GSoC.  The org
>>> application phase starts now and we'll apply.
>>> I'd propose to have 3-5 ideas available with different level of
>>> difficulty:
>>> easy:
>>> -  beaglebone target / $board target  -  including upstreaming and
>>> bugfixing
>> Nice. Would be great specially for the new beaglebone.
> I like the idea, but have doubts if it is enough work for the time of gsoc.
> We'd need to define tasks around that - e.g. debugging / remote debugging for 
> the target included.

I don't think it will be enough work for gsoc.

>>> -  work on infra (build infra or buildbot/jenkins?)
>> Nice. But what exactly? Do we still need to use chroot? If we do, we could
>> work on fakeroot or the Yocto equivalent.
> No specific Idea right now - maybe Behan has more ideas here. I'd spend more 
> time on the actual linux/llvm side.

I think this would need to include a complete rebuild of the buildbot
with a lot more test cases, multiple architecture builds etc.

>> intermediate:
>>> -  Extend buildbot for x86
>> Nice.
> Maybe not enough content wise - combine with others.

This would probably be bundled with the previous.

>>> -  Add full ltp run with reporting
>> Nice.
> Can be a good topic if done with reporting.

Same again.

>>> -  Add reporting of error/warning/msg statistics (how many warnings of
>>> type X)
>> Nice and very useful. Like a report at the end of the build: you have
>> warning X in the file.c:13 file3.c:19
>> Specially if this report could be stored by buildbot.
> Exactly.  How many errors of type "foo" happened during that build and so on:
> Example:  http://clang.debian.net/  -> rebuild results

Same again.

>>> hard:
>>> - checker
>> Do you mean the --emit-llvm and .bc? Yes, very good.
> I mean the static analysis tool.

Yeah. Getting it working with the kernel, extending it for common kernel

> Otherwise another highly experimental idea : compile the kernel to .bc  and 
> link it with llvm-link and then produce target specific code from there.
> Completely different compilation workflow as we use it right now.

A sort of half compiled kernel? I'm really not sure how this would be
useful. The BC would still be intended for a particular arch (since you
can't compile for more than one arch at a time). For a purely analysis
point of view, separate bc files would likely be all that's necessary,
and somebody has done that already.

It would probably me more about a tool around the bc files to analyze
the kernel code in some way (hopefully in a bid to make llvm toolset
more attractive to the kernel community). However, I'm not sure any of
us are qualified to specify that kind of work and/or project.

>>> - llvm macros, llvm + realmode
>> Nice. And how about llvm/clang self hosted (I mean try our builds from
>> llvm/clang built by llvm/clang)?
> Yes, but thats not really hard - we're just lazy and don't want to spend the 
> time for the extra cycles.

I agree. Self hosted clang would be trivial, and largely a waste of time.

>>> - tracing, benchmarking, fix all errors in "make allyesconfig"
>> Nice.

Some sort of complete validation suite on the complete kernel.

>> My suggestions:
>> easy:
>> - analyze common errors in mainline kernel and check if some of them could
>> be upstream. Once I found an ; in a if statement.
> This could be combined with the reporting above (how many warnings/errors of 
> type X) and so on.

This is probably merely part of the checker work above.

>> intermediate:
>> - run Android CTS test in Nexus 7 and check if it has some parts broken or
>> not. Try to fix the ones that are broken.
>> - llvm/clang self hosted.

Finishing/validating an LLVM Android build? Would be cool.

>> hard:
>> - llvm/clang for u-boot. Would be nice to see what we get from these
>> projects.
> Same - core topic ?  It helps on the boards for sure - no question. But thats 
> step 2 for us right now.
>> - llvm/clang for buildroot. Same as before.

Both of these are probably beyond the scope of our project, which is
using clang with the Linux kernel.

Ideally a gsoc candidate would help the LLVMLinux project increase the
adoption of clang with the kernel community, or help with work which
will support getting patches upstream.


Behan Webster
behanw at converseincode.com

More information about the LLVMLinux mailing list