[klee-dev] using klee without llvm-gcc?

[Daniel Liew]

On 18 March 2013 15:43, Hongxu Chen <leftcopy.chx at gmail.com> wrote:
> Thanks for your reply, Dan.
> I followed your advice using clang2.9 to build bca files and build llvm,stp
> successfully; but UCLIBC fails.
Just to say there isn't a requirement to build STP with a LLVM
compiler but the fact that it did compile is good news :)

klee has partially been built and libs like
> libkleeRuntimeIntrinsic.bca,libkleeRuntimePOSIX.bca and libklee-libc.bca has
> already came out. For uclibc, the error message is a bit confusing:
>
>     In file included from libcrypt/crypt.c:11:
>     libcrypt/libcrypt.h:11:78: error: expected function body after
> function declarator
>     extern char *__md5_crypt(const unsigned char *pw, const unsigned
> char *salt) attribute_hidden;
>
>           ^
>     libcrypt/libcrypt.h:12:78: error: expected function body after
> function declarator
>     extern char *__des_crypt(const unsigned char *pw, const unsigned
> char *salt) attribute_hidden;
>
>           ^
>     libcrypt/crypt.c:18:10: warning: implicit declaration of function
> '__md5_crypt' is invalid in C99 [-Wimplicit-function-declaration]
>                     return __md5_crypt((unsigned char*)key, (unsigned
> char*)salt);
>                            ^
>     libcrypt/crypt.c:18:10: warning: incompatible integer to pointer
> conversion returning 'int' from a function with result type 'char *'
>                     return __md5_crypt((unsigned char*)key, (unsigned
> char*)salt);
>
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     libcrypt/crypt.c:20:10: warning: implicit declaration of function
> '__des_crypt' is invalid in C99 [-Wimplicit-function-declaration]
>                     return __des_crypt((unsigned char*)key, (unsigned
> char*)salt);
>                            ^
>     libcrypt/crypt.c:20:10: warning: incompatible integer to pointer
> conversion returning 'int' from a function with result type 'char *'
>                     return __des_crypt((unsigned char*)key, (unsigned
> char*)salt);
>
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>     4 warnings and 2 errors generated.
>     make: *** [libcrypt/crypt.os] Error 1
>
> Here in Rules.mak.llvm, `LLVMGCC' has been changed to $(LLVMTOOLDIR)/clang.
> Similar error occurred when I set LLVMGCC to a pre-compiled llvm-gcc(from
> llvm2.9 download
> page,http://llvm.org/releases/2.9/llvm-gcc4.2-2.9-x86_64-linux.tar.bz2).
>
>     make: *** [libcrypt/crypt.os] Error 1
>     In file included from libcrypt/crypt.c:11:
>     libcrypt/libcrypt.h: In function '__md5_crypt':
>     libcrypt/libcrypt.h:11: error: expected declaration specifiers
> before 'attribute_hidden'
>     libcrypt/libcrypt.h:12: error: expected '=', ',', ';', 'asm' or
> '__attribute__' before 'attribute_hidden'
>     libcrypt/crypt.c:14: error: expected '=', ',', ';', 'asm' or
> '__attribute__' before '{' token
>     libcrypt/crypt.c:21: error: expected '{' at end of input
>     make: *** [libcrypt/crypt.os] Error 1
>
> I also tried the `--with-gcc' option when configuring(AFAIK, CC is set to gcc),
> and the error message is exactly the same as llvm-gcc case.
>
>     1. So has anyone else ever built
> klee-uclibc-0.02-x64/klee-uclibc-0.02-i386 with
> native gcc and met similar problems?
>     2. The `Rules.mak.llvm' actually reads
> `$(LLVMROOTDIR)//Makefile.config`, so maybe
> I again made some mistakes when building llvm?

Something very odd is happening there you shouldn't be getting parse
errors. I have never seen that problem. I can only really suggest
three things things
- It's very unlikely but check your source code for uclibc hasn't been corrupted
- run `make VERBOSE=1` and check the command being used to build
crypt.os is correct.
- I'm not really 100% sure why $(LLVMROOTDIR)/Makefile.config is being
included but I managed to build without it being included in the
makefile. You could try removing it then doing `make clean && make`

For your reference this is the command that is executed on my system
(I've shortened the llvm-gcc path) to build crypt.os

llvm-gcc --emit-llvm -c ../libcrypt/crypt.c -o ../libcrypt/crypt.os
-include ../include/libc-symbols.h -Wall -Wstrict-prototypes
-fno-strict-aliasing -fno-stack-protector -fno-builtin -nostdinc
-I../include -I. -DSTATIC -std=gnu99 -O0 -g3 -I/usr/include/ -isystem
/data/dev/KLEE/llvm-gcc/bin/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.2.1/include
-DNDEBUG -fPIC -DNOT_IN_libc -DIS_IN_libcrypt

Out of curiosity I did have a quick try at compiling
klee-uclibc-0.02-x64 using clang (version 3.1 because that's what is
on my system and llvm tools 3.1). I really do not advise it as I had
to blindly change some of the code to make it compile and I'm not sure
what the consequences are.

I hacked the Rules.mak file with..

LLVMGCC := clang
CC         = $(LLVMGCC) -emit-llvm
AR         = llvm-ar-3.0
LD         = llvm-ld-3.0
NM         = llvm-nm-3.0

The configure script included with klee-ucblic-0.02 is just a hack so
I didn't bother running it. I had to hack libc/misc/sysvipc/ipc.h
header so that the defines were set (removed #ifdef __NR_ipc and
associated #endif) and then I could run `make`.


Regards,
Dan Liew.

>
> Thanks,
> Hongxu Chen
>
>
> On Sun, Mar 17, 2013 at 10:18 PM, Daniel Liew
> <daniel.liew at imperial.ac.uk> wrote:
>>
>> On 17 March 2013 03:20, Hongxu Chen <leftcopy.chx at gmail.com> wrote:
>> > Dear all,
>> >
>> >     It seems that
>> > llvm-gcc-4.2-2.9(http://llvm.org/releases/2.9/llvm-gcc-4.2-2.9.source.tgz)
>> > suggested by the getting started page of klee has many problems and is
>> > treated as obsolete by the llvm community. For me, an internal error
>> > occurred when I built it with an debug version of llvm-2.9. So I have some
>> > questions about klee:
>>
>> It is indeed the case that llvm-gcc is obsolete. I found this when I
>> first started working on KLEE but I ignored the issue as I needed to
>> work with something that was stable.
>>
>> > Is it possible to build llvm without llvm-gcc when I have to use klee and
>> > uclibc? This page(http://klee.llvm.org/GetStarted.html) says that llvm-gcc
>> > has to be added into $PATH so that llvm would choose llvm-gcc other than gcc
>> > or clang to build llvm. The key difference is that llvm-gcc generates
>> > libkleeRuntimeIntrinsic.bca(and the related posix,uclibc runtime .bca
>> > library; this thread tells the details ). I took a glance at the configure
>> > file of llvm but didn't figure out how it is done. So I am wondering whether
>> > clang-compiled llvm also has libkleeRuntimeIntrinsic.bca and the like. I
>> > came across another project called klee-fp, which uses clang and llvm-3.0;
>> > additionally they also use uclibc, But there is a compilation error when I
>> > built klee-fp(actually the error is in the compilation of stp, which is
>> > inside klee-fp source code folder).
>> > If those .bca files can only be generated by llvm-gcc, then is there any
>> > trick when I use llvm-gcc
>> > binary(http://llvm.org/releases/2.9/llvm-gcc4.2-2.9-x86_64-linux.tar.bz2)
>> > (instead of building llvm-gcc from souce) to compile llvm? There are still
>> > some compilation errors for me.
>>
>> I tried compiling llvm-gcc from source about a year ago I couldn't get
>> anywhere with it so I just used the llvm-gcc binaries and KLEE will
>> build fine. There is nothing really stopping you as far as I know from
>> using clang instead of llvm-gcc to build libkleeRuntimeIntrinsic.bca
>> and other KLEE bitcode libraries. You should use a version of clang
>> though that uses the same version of LLVM that you intend to use with
>> KLEE. KLEE relies on LLVM's build system so for things to work in KLEE
>> so a LLVM compiler (either llvm-gcc or clang) needs to be detected
>> (i.e. in PATH) when you configure llvm for building.
>>
>> This will probably cause you a little bit of hassle if you build llvm
>> and clang from scratch as you'll probably need to build llvm and clang
>> using gcc and then build llvm again using your newly built clang
>> compiler.
>>
>> If you use your distribution's version of clang and build llvm from
>> source so that it matches your clang version you will make life easier
>> for yourself.
>>
>> Having said that, I don't believe KLEE supports LLVM 3.1 properly (the
>> IR has changed since llvm 2.9) so expect some issues to appear if you
>> use clang. I'm also not sure if KLEE's testframe work will behave if
>> you use clang instead.
>>
>> KLEE being stuck using llvm-gcc and llvm 2.9 is definitely an issue
>> which we need to address at some point. It's something that personally
>> I'd like to address as well.
>>
>> Regards,
>> Dan Liew.