run using KLEE error - klee

I am new to Klee, so I started to make the tutorials.
If for compilation I use:
llvm-gcc --emit-llvm -c -g get_sign.c and then I try to run using klee get_sign.o I get the error : KLEE: ERROR: error loading program 'get_sign.o': Invalid MODULE_CODE_GLOBALVAR record . The error is defined in the BitcodeReader.cpp file http://llvm.org/docs/doxygen/html/BitcodeReader_8cpp_source.html at line 01594.
clang (that I have used succesfully for my LLVM passes), it appears that is not possible to use it: KLEE: ERROR: error loading program 'get_sign.o': Invalid bitcode signature .
Do you know what I can do?
Also, it would be nice to give Klee inputs compiled with Clang that I already use for my passes, but as the error suggest, it is possible?
Thank you in advance !

The problem is that I installed Klee over LLVM 3.1. In the instructions from http://klee.llvm.org/GetStarted.html it is mentioned that Klee is fully compatible with LLVM 2.9. It is mentioned : "KLEE is currently tested only on Linux x86-32 and x86-64 targets, using LLVM 2.9. KLEE will not work with older LLVM versions (e.g., 2.5), and might not work with newer versions (e.g., 3.0).".
I installed Klee on LLVM 2.9 and it is working perfectly.

Related

Could not build gem5 on a machine with anaconda: "lto1: fatal error: bytecode stream"

When I tried to build gem5 with command scons build/X86/gem5.opt -j12, I received an error message saying
lto1: fatal error: bytecode stream in file '/home/beihai/anaconda3/lib/python3.8/config-3.8-x86_64-linux-gnu/libpython3.8.a' generated with LTO version 6.0 instead of the expected 8.1
I think it might be the problem of wrong gcc version. But I do not know how to fix it.
My system is Kubuntu 20.04
By running gcc -v, I got the global gcc version gcc version 9.3.0
By running /home/beihai/anaconda/envs/gem5build/bin/x86_64-conda_cos6-linux-gnu-gcc -v, I got the anaconda gcc version gcc version 7.3.0 (crosstoll-NG 1.23.0.449-a04d0)
Please tell me how to fix this problem.
I came across almost the same issue, except that mine said "LTO version 6.0 instead of the expected 6.2".
I searched for general solution for LTO compatibility issue and got some inspiration from this link: https://github.com/rust-lang/rust/issues/57176
Quick take from the above link: "I've looked into how this is related to python and found that the error only happens with python installed through anaconda."
So I removed my entire anaconda software package, and removed the build directory inside Gem5, and rerun the scon commands with an additional "--force-lto" arguments, now the installation is successful. Hope it can solve your issue as well.
The command I used: "scons --force-lto build/X86/gem5.opt -j6"
My setups is:
Ubuntu 18 withe kernel 4.15.0-134-generic
g++ --version = g++ (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0

How to set custom gcc when using gdb

I have a program that is build with a different version of the GCC than the one on the system. When I try to debug the program using GDB, I am getting errors like
libstdc++.so.6: version `GLIBCXX_3.4.20' not found
libstdc++.so.6: version `CXXABI_1.3.8' not found
libstdc++.so.6: version `GLIBCXX_3.4.21' not found
But when I build and run the executable, I get no errors.
It seems that GDB is using a different libstdc++ than the one used when building. Is there a possibility to tell GDB what libs to use ?
At build, using Makefile, there are some variables set that say what g++ to use, so it will be not the one on the system

Missing debug metadata in llvm after xcode update

I'm developing some C/C++/Objective C static analysis utility which works with llvm bytecode files. Its basic idea is quite simple:
1. Utility executes clang/clang++ with arguments "-c -emit-llvm -femit-all-decls -g" to generate llvm bytecode file for tested source file.
2. If file was created it's being read by LLVM C bindings and checked. Problems related to some specific code points are reported with source references since there are debug metadata with source references.
I've had a prototype of my utility which worked fine, but recently I've updated Xcode to 6.1 and source references became missing.
To fix this I've tried to rebuild my tool and llvm static libraries with updated compiler, but it didn't solved my problem.
I've tried to receive any hints from llvm, and the only thing I finally got is:
➜ bin ./llvm-dis test.bc
warning: ignoring debug info with an invalid version (600054001) in test.bc
So llvm-dis has shown me above warning and produced test.ll file which was stripped of any debug metadata attributes.
This is my simple test source file which I'm playing with:
int returnFive() {
return 5;
}
and some info which may be helpful:
➜ bin clang --version
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix
➜ bin ./llvm-config --version
3.5.0
➜ bin ./llvm-config --host-target
x86_64-apple-darwin14.0.0
For me this seems very compatible, but it isn't so maybe someone can give me any suggestions on how to resolve this?
While I'm still not comfortable with the solution, I've hacked LLVM code and removed the call to llvm::UpgradeDebugInfo method from BitcodeReader::MaterializeModule code. Of course I may be punished for this if some truly incompatible LLVM compiler is used, but for now it works, furthermore not only clang from XCode can be used, but as well I can use Clang from LLVM release page which also produces "debug info with invalid version (0)".

Xcode 6 throws clang error while compiling

I have recently updated my Xcode to version 6.0 (6A313). Now, during the compilation I get the following error:
clang: error: unknown argument: '-wall'
From Clang Compiler User's Manual, I found out that this flag is responsible for enabling all warnings. I have also read many posts on the temporary fix for Apple LLVM Compiler for Xcode 5.1, where users would downgrade all clang errors to warnings with:
ARCHFLAGS=-Wno-error=unused-command-line-argument-hard-error-in-future easy_install ExtensionName
However, that does not help me, as there is no such extension as "all". So I am stuck at this point and any suggestions would be appreciated.
Also, I have upgraded to Ruby 2.1.1 (from 2.0.x), but that did not seem to help either.
The argument is -Wall, not -wall.

OpenCV compilation error with gcc 4.3 or above in MAC OS X

I want to use BRIEF and ORB in OpenCV and in order to use SSE4.2 (to speed up matching) in OpenCV, we need to compile OpenCV with gcc 4.3 or above and SSE4.2 option enabled.
I have no problem compiling OpenCV with gcc4.2.1 which is the default version in my Mac OS X 10.6.8.
Then, I have tried using Macports to install gcc4.3, 4.4, 4.5, 4.6, 4.7, 4.8 and switched gcc to the new one. I first tried installing OpenCV with default settings like instruction in OpenCV website. But I couldn't compile the code like when I used gcc4.2.1. Please note that, no problem with gcc4.2.1. Problems happen with gcc4.3 or above.
Could you please give me an advice where the problems come from? It seems that the errors come from compiler compatibility.
Some errors are:
OpenCV-2.4.0/modules/highgui/src/window_cocoa.mm: In function 'void cvDestroyAllWindows()':
OpenCV-2.4.0/modules/highgui/src/window_cocoa.mm:198:21: error: expected ';' before 'in'
OpenCV-2.4.0/modules/highgui/src/window_cocoa.mm:198:21: error: 'in' was not declared in this scope
OpenCV-2.4.0/modules/highgui/src/window_cocoa.mm:198:24: error: expected ';' before 'list'
In file included from /opt/local/include/libavformat/avformat.h:42:0,
from OpenCV-2.4.0/modules/highgui/src/ffmpeg_codecs.hpp:78,
from OpenCV-2.4.0/modules/highgui/src/cap_ffmpeg_impl.hpp:56,
from OpenCV-2.4.0/modules/highgui/src/cap_ffmpeg.cpp:45:
/opt/local/include/libavcodec/avcodec.h:554:1: internal compiler error: Segmentation fault
Please submit a full bug report,
The issue is that for(NSString *key in list) in window_cocoa.mm is an Objective-C 2 construct and is compiled as Objective-C++
gcc from GNU does not support the version 2 syntax and so cannot compile this. gcc4.2 from Apple includes Apple extensions including Objective C 2 but pure gcc does not.
You'll have to try the clang compiler.

Resources