[klee-dev] uclibc status

[Martin Nowack]

Hi Daniel,

> I'm starting to look at getting KLEE up to scratch (it's going to be a
> long process) this week and one of the things on my to do list is
> uclibc. The old version would not compile on my machine due to changes
> in my kernel headers.
Sounds great. Which kernel version do you have?
It works quite well for a current Ubuntu 13.04 with a 3.8.0 kernel.

> 
> I see there is now a klee-uclibc repository [1] but I'm not sure what
> work has and has not been done, there seem to be quite a few branches.
The repository is a complete clone of upstream, maybe eventually we should remove
unused branches and just keep newer ones including the changes.

> Seeing as you seem to have done the most work here could you explain
> to me (and the rest of the KLEE community -- note I've CC'ed the
> mailing list) what each branch is for and summarise what work you have
> done (I don't want to duplicate your efforts).
As far as I know, the existing KLEE uclibc version is based on the 0_9_29 tag.
Note that the 0_9_29 branch contains the 0_9_29 tag plus a couple of back ports.

There are currently two additional branches:
a) klee_monolithic: which is based on the 0_9_29 tag and contains the original KLEE modifications.
b) klee_monolithic_llvm33: which contains in addition modifications for LLVM 3.3 and more recent kernel versions (and is rebased to the the 0_9_29 branch) plus additional back ports.


> Would you also be able to recommend one or more starting points for
> uclibc versions? I'd like to get the old uclibc (monolithic) up and
> running on my machine with llvm-gcc so I can fix some outstanding
> issues on llvm2.9, then I'd like start experimenting with LLVM3.3 so I
> can see what needs working on (I'm very keen for us to move to
> clang... I'm not a fan of llvm-gcc).
List of steps I use to get it up and running (but for LLVM 3.3 and the klee_monolithic_llvm33 branch):

1. Compile or install dragonegg [2]
2. Make sure llvm-config is in your executables path
3. run ./configure —with-llvm=build_directory_of_llvm
4. configure your uclibc
   a) make menuconfig (install libncurses5-dev on Ubuntu)
   b) make sure you set your architecture accordingly
   c) make sure the configuration points to your kernel headers: “Target Architecture Feature and Options” -> "Linux kernel header location" (on Ubuntu e.g. /usr/include/x86_64-linux-gnu/ )
   d) compile it with make (if you compiled dragon egg under 1. than provide that directory as an argument with make DRAGONEGGDIR=/path/to/it )

Dragonegg is currently needed as not all compiler flags are supported by clang but works quite stable.

For LLVM 2.9 I can’t tell you.
I made some some minor modifications to the build system to use dragon egg therefore LLVM 2.9 won’t work with the current llvm33 branch.

> 
> We also ideally need some sort of strategy for merging with upstream
> uclibc... I presume the branches with version numbers are official
> releases... should we branch off those?.. i.e.
> 
> 0_9_28_klee
> 0.9.33_klee
> 
Backporting changes from upstream should be easier with the cloned repository.

Yes, that schema looks reasonable for me.
Just watch out, sometimes they used the same name for a tag and for a branch.

Thanks for all your effort.

In case there are any questions, please let me know.

Cheers,
Martin

> [1] https://github.com/ccadar/klee-uclibc
[2] http://dragonegg.llvm.org/

---------------------------------------------------
Martin Nowack
Research Assistant

Technische Universität Dresden
Computer Science
Institute of Systems Architecture
Systems Engineering
01062 Dresden
----------------------------------------------------