[llvmlinux] GSoC project ideas brainstorm

Marcelo Sousa marceloabsousa at gmail.com
Tue Mar 19 21:50:47 UTC 2013


Hello,

I'm developing a type-based static analysis tool for LLVM IR and I'm
going to test it against the Kernel soon.
It would be great if you could provide information on how to do
generate the bytecode files for X86. I was able to hack my way through
for vexpress but X86 would be nicer.

Regards,
Marcelo

On Tue, Mar 19, 2013 at 8:01 PM, Jan-Simon Möller <dl9pf at gmx.de> wrote:
> 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
> _______________________________________________
> LLVMLinux mailing list
> LLVMLinux at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/llvmlinux


More information about the LLVMLinux mailing list