uclibc status

[Daniel Liew]

Hi Martin,

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.

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.

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

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

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

Thanks,
Dan Liew.

[1] https://github.com/ccadar/klee-uclibc

[Martin Nowack]

Hi Daniel,

Post by Daniel Liew
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.

Post by Daniel Liew
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.

Post by Daniel Liew
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.

Post by Daniel Liew
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.

Post by Daniel Liew
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

Post by Daniel Liew
[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
----------------------------------------------------

[Daniel Liew]

Post by Martin Nowack
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'm running Arch Linux with kernel 3.11.6

Post by Martin Nowack
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.

Great. I just made a pull request to klee_monolithic with some fixes
for my system ( https://github.com/ccadar/klee-uclibc/pull/1 ). They
need testing on older systems before being accepted.

Post by Martin Nowack

Post by Daniel Liew
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).

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.

Oh... I've not really played with dragonegg. I would prefer clang
seeing as that's what I would like to use when building with LLVM3.3.
I know the KLEE-CL version of uclibc works with clang (
git://git.pcc.me.uk/~peter/klee-uclibc.git )

Thanks for the instructions. I'll investigate the
klee_monolithic_llvm33 branch when I have time.

Thanks,
Dan Liew.