KLEE failed to build cleanly with LLVM 3.3

Discussion:

Mark R. Tuttle

2014-09-17 19:10:45 UTC

I just did a "git pull" to grab the latest commit (2497fdc) and ran into
trouble building against LLVM 3.3 and running the regression tests.

*Build failed *in file src/tools/klee/main.cpp in function
KleeHandler::openOutputFile

#if LLVM_VERSION_CODE >= LLVM_VERSION(3,5)
f = new llvm::raw_fd_ostream(path.c_str(), Error, llvm::sys::fs::F_None);
#elif LLVM_VERSION_CODE >= LLVM_VERSION(3,0)
f = new llvm::raw_fd_ostream(path.c_str(), Error,
llvm::sys::fs::F_Binary);
#else
f = new llvm::raw_fd_ostream(path.c_str(), Error,
llvm::raw_fd_ostream::F_Binary);
#endif

because llvm::sys::fs::F_Binary was not defined. LLVM 3.3 source code
seems to define llvm::raw_fd_ostream::F_Binary and not
llvm::sys::fs:F_Binary. I changed the reference to LLVM version 3.0 to 3.4
and the build succeeded.

*Regression tests failed *with

Failing Tests (20):
KLEE :: Concrete/BitwiseOps.ll
KLEE :: Concrete/BoolReadWrite.ll
KLEE :: Concrete/Casts.ll
KLEE :: Concrete/CmpEq.ll
KLEE :: Concrete/ConstantExpr.ll
KLEE :: Concrete/FloatingPointOps.ll
KLEE :: Concrete/GlobalInitializers.ll
KLEE :: Concrete/GlobalUndef.ll
KLEE :: Concrete/GlobalVariable.ll
KLEE :: Concrete/ICmp.ll
KLEE :: Concrete/OneCall.ll
KLEE :: Concrete/OverlappingPhiNodes.ll
KLEE :: Concrete/Select.ll
KLEE :: Concrete/Shifts.ll
KLEE :: Concrete/SimpleStoreAndLoad.ll
KLEE :: Concrete/UnconditionalBranch.ll
KLEE :: Concrete/UnconditionalBranchWithSimplePhi.ll
KLEE :: Concrete/UnorderedPhiNodes.ll
KLEE :: Concrete/ackermann.c
KLEE :: Concrete/arith_test.ll

Expected Passes : 131
Expected Failures : 2
Unsupported Tests : 1
Unexpected Failures: 20

Each regression failure generates output of the form

Command 0 Stderr:
Traceback (most recent call last):
File "ROOT/klee/src/test/Concrete/ConcreteTest.py", line 72, in <module>
main()
File "ROOT/klee/src/test/Concrete/ConcreteTest.py", line 69, in main
testFile(test_name, opts.klee_path, opts.lli_path)
File "ROOT/klee/src/test/Concrete/ConcreteTest.py", line 26, in testFile
lliOut = subprocess.check_output(lli_cmd).decode()
AttributeError: 'module' object has no attribute 'check_output'

I'm using Python2 and ConcreteTest.py line 26 refers to Python3. Using
Python3 fails with an error pointing to the LLVM 3.3 source tree

Traceback (most recent call last):
File "ROOT/llvm/3.3/src/utils/lit/lit.py", line 4, in <module>
import lit
File "ROOT/llvm/3.3/src/utils/lit/lit/__init__.py", line 3, in <module>
from main import main
ImportError: No module named main

Any advice on how to proceed?

Thanks,
Mark

Mark Tuttle, tuttle-***@public.gmane.org

Daniel Liew

2014-09-17 19:39:13 UTC

Permalink

Post by Mark R. Tuttle
I just did a "git pull" to grab the latest commit (2497fdc) and ran into
trouble building against LLVM 3.3 and running the regression tests.
Build failed in file src/tools/klee/main.cpp in function
KleeHandler::openOutputFile
#if LLVM_VERSION_CODE >= LLVM_VERSION(3,5)
f = new llvm::raw_fd_ostream(path.c_str(), Error, llvm::sys::fs::F_None);
#elif LLVM_VERSION_CODE >= LLVM_VERSION(3,0)
f = new llvm::raw_fd_ostream(path.c_str(), Error,
llvm::sys::fs::F_Binary);
#else
f = new llvm::raw_fd_ostream(path.c_str(), Error,
llvm::raw_fd_ostream::F_Binary);
#endif
because llvm::sys::fs::F_Binary was not defined. LLVM 3.3 source code seems
to define llvm::raw_fd_ostream::F_Binary and not llvm::sys::fs:F_Binary. I
changed the reference to LLVM version 3.0 to 3.4 and the build succeeded.

We are currently targeting LLVM2.9 and LLVM3.4 [1] and are not testing
LLVM3.3 build support. Do you need to use LLVM3.3 for any particular
reason?

We'd happily accept a patch to fix your compilation error provided it
doesn't break the configurations we're testing right now.

Post by Mark R. Tuttle
Regression tests failed with
KLEE :: Concrete/BitwiseOps.ll
KLEE :: Concrete/BoolReadWrite.ll
KLEE :: Concrete/Casts.ll
KLEE :: Concrete/CmpEq.ll
KLEE :: Concrete/ConstantExpr.ll
KLEE :: Concrete/FloatingPointOps.ll
KLEE :: Concrete/GlobalInitializers.ll
KLEE :: Concrete/GlobalUndef.ll
KLEE :: Concrete/GlobalVariable.ll
KLEE :: Concrete/ICmp.ll
KLEE :: Concrete/OneCall.ll
KLEE :: Concrete/OverlappingPhiNodes.ll
KLEE :: Concrete/Select.ll
KLEE :: Concrete/Shifts.ll
KLEE :: Concrete/SimpleStoreAndLoad.ll
KLEE :: Concrete/UnconditionalBranch.ll
KLEE :: Concrete/UnconditionalBranchWithSimplePhi.ll
KLEE :: Concrete/UnorderedPhiNodes.ll
KLEE :: Concrete/ackermann.c
KLEE :: Concrete/arith_test.ll
Expected Passes : 131
Expected Failures : 2
Unsupported Tests : 1
Unexpected Failures: 20
Each regression failure generates output of the form
File "ROOT/klee/src/test/Concrete/ConcreteTest.py", line 72, in <module>
main()
File "ROOT/klee/src/test/Concrete/ConcreteTest.py", line 69, in main
testFile(test_name, opts.klee_path, opts.lli_path)
File "ROOT/klee/src/test/Concrete/ConcreteTest.py", line 26, in testFile
lliOut = subprocess.check_output(lli_cmd).decode()
AttributeError: 'module' object has no attribute 'check_output'

What version of python2 are you using? I have 2.7.8 and it works fine.

Post by Mark R. Tuttle
I'm using Python2 and ConcreteTest.py line 26 refers to Python3. Using
Python3 fails with an error pointing to the LLVM 3.3 source tree

It's likely that the version of llvm-lit in the LLVM3.3 source tree
doesn't support Python3

As a temporary work around you could change

#!/usr/bin/python

to the path to your Python3 installation in ConcreteTest.py

[1] https://travis-ci.org/klee/klee

Thanks,
Dan.

Mark R. Tuttle

2014-09-17 21:13:33 UTC

Permalink

I've been scared away from LLVM 3.4 by KLEE's dire "experimental support
only" warnings for 3.4. May I shift to 3.4 now?

I'm using python 2.7.5. I'll debug more deeply, I'll now bet you dinner
the problem is my site's installation of python.

What is the reference to https://travis-ci.org/klee/klee? I've been using
https://github.com/klee/klee.git

Thanks for the quick response.
Mark

Post by Mark R. Tuttle

llvm::sys::fs::F_None);

Post by Mark R. Tuttle
#elif LLVM_VERSION_CODE >= LLVM_VERSION(3,0)
f = new llvm::raw_fd_ostream(path.c_str(), Error,
llvm::sys::fs::F_Binary);
#else
f = new llvm::raw_fd_ostream(path.c_str(), Error,
llvm::raw_fd_ostream::F_Binary);
#endif
because llvm::sys::fs::F_Binary was not defined. LLVM 3.3 source code

seems

Post by Mark R. Tuttle
to define llvm::raw_fd_ostream::F_Binary and not

llvm::sys::fs:F_Binary. I

Post by Mark R. Tuttle
changed the reference to LLVM version 3.0 to 3.4 and the build succeeded.

We are currently targeting LLVM2.9 and LLVM3.4 [1] and are not testing
LLVM3.3 build support. Do you need to use LLVM3.3 for any particular
reason?
We'd happily accept a patch to fix your compilation error provided it
doesn't break the configurations we're testing right now.

Post by Mark R. Tuttle
main()
File "ROOT/klee/src/test/Concrete/ConcreteTest.py", line 69, in main
testFile(test_name, opts.klee_path, opts.lli_path)
File "ROOT/klee/src/test/Concrete/ConcreteTest.py", line 26, in

testFile

Post by Mark R. Tuttle
lliOut = subprocess.check_output(lli_cmd).decode()
AttributeError: 'module' object has no attribute 'check_output'

What version of python2 are you using? I have 2.7.8 and it works fine.

Post by Mark R. Tuttle
I'm using Python2 and ConcreteTest.py line 26 refers to Python3. Using
Python3 fails with an error pointing to the LLVM 3.3 source tree

It's likely that the version of llvm-lit in the LLVM3.3 source tree
doesn't support Python3
As a temporary work around you could change
#!/usr/bin/python
to the path to your Python3 installation in ConcreteTest.py
[1] https://travis-ci.org/klee/klee
Thanks,
Dan.

Daniel Liew

2014-09-17 21:41:49 UTC

Permalink

Post by Mark R. Tuttle
I've been scared away from LLVM 3.4 by KLEE's dire "experimental support
only" warnings for 3.4. May I shift to 3.4 now?

Well LLVM3.3 support was always experimental as well. At this point if
you need to use a version of LLVM newer than 2.9 then 3.4 is your best
bet.

Post by Mark R. Tuttle
I'm using python 2.7.5. I'll debug more deeply, I'll now bet you dinner the
problem is my site's installation of python.
What is the reference to https://travis-ci.org/klee/klee? I've been using
https://github.com/klee/klee.git

Oh this our newly set up continuous integration test set up which uses
Travis. If you look you'll see several lines that look like

LLVM_VERSION=3.4 STP_VERSION=UPSTREAM KLEE_UCLIBC=0
DISABLE_ASSERTIONS=0 ENABLE_OPTIMIZED=1

each one of these is a configuration we are building and testing. You
can click on one of them to see what happened during a build.

The source code is still located at https://github.com/klee/klee.git

Sean Bartell

2014-09-23 03:08:22 UTC

Permalink

Hello,

Post by Daniel Liew

We are currently targeting LLVM2.9 and LLVM3.4 [1] and are not testing
LLVM3.3 build support. Do you need to use LLVM3.3 for any particular
reason?
We'd happily accept a patch to fix your compilation error provided it
doesn't break the configurations we're testing right now.

I had the same problem a while ago, and it turns out the correct guard
is >= LLVM_VERSION(3,4). I've attached a patch.

Thanks,
Sean Bartell

Cristian Cadar

2014-09-23 08:14:47 UTC

Permalink

Thanks, Sean. The preferred way to submit patches is via pull requests
on GitHub (http://klee.github.io/klee/developers-guide.html#github), but
I'm happy to incorporate this small patch manually if you prefer.

Cristian

Post by Sean Bartell
Hello,

Post by Daniel Liew

We are currently targeting LLVM2.9 and LLVM3.4 [1] and are not testing
LLVM3.3 build support. Do you need to use LLVM3.3 for any particular
reason?
We'd happily accept a patch to fix your compilation error provided it
doesn't break the configurations we're testing right now.

I had the same problem a while ago, and it turns out the correct guard
is >= LLVM_VERSION(3,4). I've attached a patch.
Thanks,
Sean Bartell
_______________________________________________
klee-dev mailing list
https://mailman.ic.ac.uk/mailman/listinfo/klee-dev