[klee-dev] klee with llvm-3.6?

[Willem Pinckaers]

Hi,

I have a running version of Klee with llvm-3.6, with the caveat that external support and linking has been removed/disabled in it.

The below is a short overview from my current incomplete understanding of Klee + LLVM-3.6. Klee and LLVM developers on the list might have more information.

The main changes are removal of the old JIT (which means the code used to call external functions doesn’t work anymore) and a lot of changes to the code used in linking, other changes are minor.

The get external call working again seems to require a decent amount of work. In particular MCJit will only call functions with a signature similar to main (see MCJIT::runFunction) and Lazy code emitting requires some work, see http://blog.llvm.org/2013/07/using-mcjit-with-kaleidoscope-tutorial.html <http://blog.llvm.org/2013/07/using-mcjit-with-kaleidoscope-tutorial.html>, maybe the LazyFunctionCreator makes this easier. An alternative might be using libffi, see an example on http://eli.thegreenplace.net/2013/03/04/flexible-runtime-interface-to-shared-libraries-with-libffi <http://eli.thegreenplace.net/2013/03/04/flexible-runtime-interface-to-shared-libraries-with-libffi>

3.6 had a fair amount of changes to the code KLEE uses to link bitcode files and archives (which is old code from LLVM that when it was removed from LLVM in I think 3.3 and then was copied into Klee). Instead of fixing these I opted to remove linking support from Klee itself. Instead I link the bitcode files before giving them to Klee. 

There was some discussion about linking in Klee earlier on github (https://github.com/klee/klee/pull/141 <https://github.com/klee/klee/pull/141>). My preference is to remove all linking from Klee. A provided wrapper script can do the necessary linking using llvm-link and possibly some opt calls for internalization of functions and global dead code elimination. What are the current plans for linking within Klee?

It seems getting externals to work with LLVM-3.6 might require a decent amount of work. Does anyone know if there would be a more straight forward way using MCJit? 


Regards,
    Willem



> On Mar 20, 2015, at 5:28 AM, Eissfeldt, Heiko <heiko.eissfeldt at siemens.com> wrote:
> 
> Hello,
>  
> I am currently struggling compiling current klee with the current llvm-3.6-release.
> I used the receipt from http://klee.github.io/experimental/ <http://klee.github.io/experimental/> (replacing 3.4 with 3.6),
> and noted quite some interface changes from within llvm…
>  
> To avoid duplicated work, are there any other people doing this adaption already?
>  
> My first goal is to get klee compiled, then send the necessary patches to some knowledgable person for review and possible inclusion.
>  
> Has there even been a decision to never upgrade to llvm-3.6?
>  
> Thanks, Heiko
>  
> _______________________________________________
> klee-dev mailing list
> klee-dev at imperial.ac.uk <mailto:klee-dev at imperial.ac.uk>
> https://mailman.ic.ac.uk/mailman/listinfo/klee-dev <https://mailman.ic.ac.uk/mailman/listinfo/klee-dev>
-------------- next part --------------
HTML attachment scrubbed and removed