[llvmlinux] GSoC project ideas brainstorm

Jan-Simon Möller dl9pf at gmx.de
Tue Mar 19 20:01:33 UTC 2013


Hi !


So let me summarize for now:

a) buildbot - complete rebuild with reporting, testsuite and more arch support

b) checker or static analysis of bc files  (llvm/clang)

c) allyesconfig, tracing, validation suite  (kernel)


If we agree on these, we can start to specify more closely.

Comments inline:

Am Dienstag, 19. März 2013, 15:08:50 schrieb Behan Webster:
> 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.

Agreed.

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

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

If we think in the usual path ;)  - yes, what you say is true for  /arch/* .
This would be arch/cpu specific. Right. I wonder: What about the "rest" ;)  

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


Best,

Dipl.-Ing.
Jan-Simon Möller

jansimon.moeller at gmx.de


More information about the LLVMLinux mailing list