On Mon, Nov 2, 2009 at 1:31 AM, Daniel Dunbar <daniel at zuster.org> wrote: > > ENABLE_OPTIMIZED is used in the top-level LLVM makefiles, which KLEE > reuses. If you build with 'make ENABLE_OPTIMIZED=0' you should get a > Debug version of klee (you will need to build LLVM with > ENABLE_OPTIMIZED=0 as well) in the Debug/bin directory, which will > ideally give you symbols in the back trace. >
Ah, okay - I had tried just removing it with no effect. I also had to rebuild LLVM in debug mode (otherwise I got a build error in "tools" which was trying to look for "Debug/llvm-config" in the LLVM build dir), which then produced this error: make[2]: Entering directory `/home/mlcreech/klee/klee-trunk/runtime/Intrinsic' llvm[2]: Compiling klee_div_zero_check.c for Release build (bytecode) make[2]: *** No rule to make target `/home/mlcreech/klee/llvm/Release/bin/llvm-as', needed by `/home/mlcreech/klee/klee-trunk/runtime/Intrinsic/Release/klee_div_zero_check.bc'. Stop. Working around that by just symlinking "Release" to "Debug" in LLVM worked, though. :) I still get unresolved symbols, but the backtrace is a little more complete (and has 10 more frames, oddly): $ klee --only-output-states-covering-new --libc=uclibc test.o 0 klee 0x00000000012367de 1 klee 0x0000000001236657 2 libpthread.so.0 0x00007f1f3d83d9c0 3 klee 0x00000000009a2198 llvm::Value::getValueID() const + 12 4 klee 0x0000000000c18c7d bool llvm::isa_impl<llvm::Constant, llvm::Value>(llvm::Value const&) + 24 5 klee 0x0000000000c1a881 llvm::isa_impl_wrap<llvm::Constant, llvm::Value const, llvm::Value const>::doit(llvm::Value const&) + 24 6 klee 0x0000000000c1a6ea bool llvm::isa_impl_cl<llvm::Value>::isa<llvm::Constant>(llvm::Value const&) + 24 7 klee 0x0000000000c8d00d bool llvm::isa_impl_cl<llvm::Value const>::isa<llvm::Constant>(llvm::Value const&) + 24 8 klee 0x0000000000c864c4 bool llvm::isa_impl_cl<llvm::Value const*>::isa<llvm::Constant>(llvm::Value const*) + 24 9 klee 0x0000000000c827a6 bool llvm::isa<llvm::Constant, llvm::Value const*>(llvm::Value const* const&) + 27 10 klee 0x0000000000c83b24 llvm::cast_retty<llvm::Constant, llvm::Value const*>::ret_type llvm::dyn_cast<llvm::Constant, llvm::Value const*>(llvm::Value const* const&) + 24 11 klee 0x0000000000d7fae6 12 klee 0x0000000000d8010e 13 klee 0x0000000000d8010e 14 klee 0x0000000000d8010e 15 klee 0x0000000000d83a9d 16 klee 0x0000000000d83ca6 17 klee 0x0000000000d84ea5 llvm::Linker::LinkModules(llvm::Module*, llvm::Module*, std::string*) + 2105 18 klee 0x0000000000d7da3f llvm::Linker::LinkInModule(llvm::Module*, std::string*) + 47 19 klee 0x0000000000d8ec59 llvm::Linker::LinkInArchive(llvm::sys::Path const&, bool&) + 1773 20 klee 0x0000000000d7d5e6 llvm::Linker::LinkInFile(llvm::sys::Path const&, bool&) + 1120 21 klee 0x000000000095aba2 klee::linkWithLibrary(llvm::Module*, std::string const&) + 98 22 klee 0x000000000090607a 23 klee 0x000000000090713b main + 1035 24 libc.so.6 0x00007f1f3cb4ea3d __libc_start_main + 253 25 klee 0x00000000008fff19 Segmentation fault > > Not offhand. Does it still crash if you don't pass -g when building > test.o? I assume you are building with llvm-gcc from LLVM 2.6? Also, > what version of gcc are you using to build LLVM? > Yes, it still crashes if I compile the test code without "-g". mlcreech at localhost ~/klee $ llvm-gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../src/configure --enable-llvm=/home/nlewycky/local/2.6/llvm-2.6 --prefix=/home/nlewycky/local/2.6/llvm-gcc/install --enable-languages=c,c++ --program-prefix=llvm- : (reconfigured) ../src/configure --enable-llvm=/home/nlewycky/local/2.6/llvm-2.6 --prefix=/home/nlewycky/local/2.6/llvm-gcc/install --program-prefix=llvm- --enable-languages=c,c++,fortran : (reconfigured) ../src/configure --enable-llvm=/home/nlewycky/local/2.6/llvm-2.6 --prefix=/home/nlewycky/local/2.6/llvm-gcc/install --program-prefix=llvm- --enable-languages=c,c++,fortran Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5649) (LLVM build) mlcreech at localhost ~/klee $ gcc -v Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.4.2/work/gcc-4.4.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.4.2/python --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.2 p1.0' Thread model: posix gcc version 4.4.2 (Gentoo 4.4.2 p1.0) > > If you want to run klee in gdb and get a backtrace and perhaps the > result of 'info locals' in the crashing function, that might give a > clue. > Sure, I'll try that later tonight. Thanks for the help. Also, thanks to all you guys for making KLEE available. I reviewed the group's EXE paper a couple of years back, and thought it was a fantastic idea but didn't know whether it'd ever see the light of day as a practical tool. It's nice to see the same approach being reimplemented & improved in KLEE! -- Matthew L. Creech
