Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[cmake] klee does not build without -fno-rtti #508

Closed
jirislaby opened this issue Nov 20, 2016 · 21 comments
Closed

[cmake] klee does not build without -fno-rtti #508

jirislaby opened this issue Nov 20, 2016 · 21 comments
Labels

Comments

@jirislaby
Copy link
Contributor

@jirislaby jirislaby commented Nov 20, 2016

@delcypher: I use this llvm 3.4:
https://build.opensuse.org/package/show/home:jirislaby:statica/llvm34

And building of klee fails with:

: && /usr/bin/c++   -std=gnu++98 -Wall -Wextra -Wno-unused-parameter -O2 -g   tools/kleaver/CMakeFiles/kleaver.dir/main.cpp.o  -o bin/kleaver  -rdynamic lib/libkleaverSolver.a lib/libkleeBasic.a lib/libkleaverSolver.a lib/libkleeBasic.a lib/libkleaverExpr.a lib/libkleeSupport.a /usr/lib64/libstp.so.2.1.2 -lboost_program_options-mt -lminisat -lz -ltcmalloc /opt/llvm-3.4.2/lib/libLLVMSupport.so -L/opt/llvm-3.4.2/lib  -lrt -ldl -lpthread -Wl,-rpath,/opt/llvm-3.4.2/lib: && :
tools/kleaver/CMakeFiles/kleaver.dir/main.cpp.o:(.rodata+0xbf0): undefined reference to `typeinfo for llvm::cl::GenericOptionValue'
tools/kleaver/CMakeFiles/kleaver.dir/main.cpp.o:(.rodata+0xd08): undefined reference to `typeinfo for llvm::cl::generic_parser_base'
tools/kleaver/CMakeFiles/kleaver.dir/main.cpp.o:(.rodata+0xd70): undefined reference to `typeinfo for llvm::cl::Option'
tools/kleaver/CMakeFiles/kleaver.dir/main.cpp.o:(.rodata+0xdf8): undefined reference to `typeinfo for llvm::cl::GenericOptionValue'
tools/kleaver/CMakeFiles/kleaver.dir/main.cpp.o:(.rodata+0xf10): undefined reference to `typeinfo for llvm::cl::generic_parser_base'
tools/kleaver/CMakeFiles/kleaver.dir/main.cpp.o:(.rodata+0xf70): undefined reference to `typeinfo for llvm::cl::Option'

and more.

I have to use:

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -177,6 +177,7 @@ set(KLEE_COMPONENT_CXX_DEFINES "")
 set(KLEE_COMPONENT_CXX_FLAGS "")
 set(KLEE_SOLVER_LIBRARIES "")
 set(KLEE_COMPONENT_EXTRA_LIBRARIES "")
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-rtti")
 
 ################################################################################
 # Find LLVM

Cmake should detect this somehow and pass -fno-rtti if needed. We actually can always?

@delcypher
Copy link
Contributor

@delcypher delcypher commented Nov 20, 2016

@jirislaby The CMake build system is supposed to handle this. In the root CMakeLists.txt file there is this

###############################################################################
# RTTI
###############################################################################
if (NOT LLVM_ENABLE_RTTI)
  if (ENABLE_SOLVER_METASMT)
    message(WARNING "Not disabling RTTI because metaSMT uses them")
    # FIXME: Should this be FATAL_ERROR rather than ERROR?
    message(WARNING
      "This build configuration is not supported and will likely not work."
      "You should recompile LLVM with RTTI enabled.")
  else()
    klee_component_add_cxx_flag("-fno-rtti" REQUIRED)
  endif()
endif()

This suggests that LLVM_ENABLE_RTTI for your build is set to ON (or its equivalent).

During configure the value of LLVM_ENABLE_RTTI is shown

-- LLVM_CONFIG_BINARY: /home/dan/dev/klee/llvm/build/Release+Debug+Asserts/bin/llvm-config
-- LLVM_PACKAGE_VERSION: "3.4.2"
-- LLVM_VERSION_MAJOR: "3"
-- LLVM_VERSION_MINOR: "4"
-- LLVM_VERSION_PATCH: "2"
-- LLVM_DEFINITIONS: "-D_GNU_SOURCE;-D__STDC_CONSTANT_MACROS;-D__STDC_FORMAT_MACROS;-D__STDC_LIMIT_MACROS"
-- LLVM_ENABLE_ASSERTIONS: "ON"
-- LLVM_ENABLE_EH: "OFF"
-- LLVM_ENABLE_RTTI: "OFF"
-- LLVM_INCLUDE_DIRS: "/home/dan/dev/klee/llvm/llvm-3.4.2.src/include;/home/dan/dev/klee/llvm/build/include"
-- LLVM_LIBRARY_DIRS: "/home/dan/dev/klee/llvm/build/Release+Debug+Asserts/lib"
-- LLVM_TOOLS_BINARY_DIR: "/home/dan/dev/klee/llvm/build/Release+Debug+Asserts/bin"

The variable comes from cmake/find_llvm.cmake. You'll have to take a look at see what's going wrong.

If you're using the llvm-config binary (the default) rather than find_package(LLVM CONFIG) then the relevant code is:

  set(LLVM_ENABLE_ASSERTIONS ON)
  set(LLVM_ENABLE_EH ON)
  set(LLVM_ENABLE_RTTI ON)
  _run_llvm_config(_llvm_cxx_flags "--cxxflags")
  string_to_list("${_llvm_cxx_flags}" _llvm_cxx_flags_list)
  foreach (flag ${_llvm_cxx_flags_list})
    if ("${flag}" STREQUAL "-DNDEBUG")
      # Note we don't rely on `llvm-config --build-mode` because
      # that seems broken when LLVM is built with CMake.
      set(LLVM_ENABLE_ASSERTIONS OFF)
    elseif ("${flag}" STREQUAL "-fno-exceptions")
      set(LLVM_ENABLE_EH OFF)
    elseif ("${flag}" STREQUAL "-fno-rtti")
      set(LLVM_ENABLE_RTTI OFF)
    endif()
  endforeach()
@delcypher
Copy link
Contributor

@delcypher delcypher commented Nov 20, 2016

@jirislaby I just noticed you're using CMake to build LLVM. That's a configuration I haven't tested so there might be something wrong or different about the way llvm-config behaves.

@jirislaby
Copy link
Contributor Author

@jirislaby jirislaby commented Nov 20, 2016

Hmm, no -fno-rtti in the flags. It may also well be that llvm 3.4 does not emit that to flags.

$ llvm-config --cxxflags
-I/opt/llvm-3.4.2/include  -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wnon-virtual-dtor -fmessage-length=0 -grecord-gcc-switches -Og -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -g   -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS

Let me investigate further.

@delcypher
Copy link
Contributor

@delcypher delcypher commented Nov 20, 2016

@jirislaby Okay yeah here's the problem.

When you build LLVM 3.4 with CMake the llvm-config binary gives misleading output.

I can see LLVM is building itself with -fno-rtti. However the output of the generated llvm-config binary when built with CMake is

$ llvm-config --cxxflags
-I/home/dan/dev/klee/llvm/llvm-3.4.2.src/include -I/home/dan/dev/klee/llvm/build_cmake/include 
-fPIC -fvisibility-inlines-hidden
-Wall
-W
-Wno-unused-parameter
-Wwrite-strings
-Wno-missing-field-initializers -pedantic
-Wno-long-long
-Wno-maybe-uninitialized
-Wnon-virtual-dtor
-D_GNU_SOURCE
-D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS

but when llvm is built using the Autoconf/Makefile the output is

$ llvm-config --cxxflags
-I/home/dan/dev/klee/llvm/llvm-3.4.2.src/include -I/home/dan/dev/klee/llvm/build/include
-D_DEBUG
-D_GNU_SOURCE
-D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS
-O3 -fomit-frame-pointer
-g
-fvisibility-inlines-hidden
-fno-exceptions
-fno-rtti
-fPIC
-Woverloaded-virtual
-Wcast-qual

So this looks like a bug in LLVM 3.4

@delcypher
Copy link
Contributor

@delcypher delcypher commented Nov 20, 2016

@jirislaby I think you might just have to build LLVM using the old build system when using 3.4. Unfortunately using the find_package(LLVM CONFIG) method won't work with LLVM 3.4 because it doesn't define all the variables we need. LLVM_ENABLE_EH, LLVM_ENABLE_RTTI and LLVM_ENABLE_ASSERTIONS variables didn't exist at that time.

@jirislaby
Copy link
Contributor Author

@jirislaby jirislaby commented Nov 20, 2016

ugh, I am looking forward when #385 is merged. Thanks for checking.

@delcypher
Copy link
Contributor

@delcypher delcypher commented Nov 20, 2016

@jirislaby Unfortunately I can't think of a good way to fix this. If LLVM can't tell KLEE's build system that it was built with -fno-rtti then there's not much we can do.

@jirislaby
Copy link
Contributor Author

@jirislaby jirislaby commented Nov 20, 2016

commit 0a8f7a16c005e1f2ffd4ca83aeb751305a5cbaeb
Author: Chris Bieneman <beanz@apple.com>
Date:   Fri Aug 14 16:20:31 2015 +0000

    [CMake] Fix PR14200, llvm-config output misses -fno-rtti

and

$ git branch -r --contains 0a8f7a16c005e1f2ffd4ca83aeb751305a5cbaeb
  origin/HEAD -> origin/master
  origin/master
  origin/release_38
  origin/release_39
  origin/stable
  origin/testing

suggest that only 3.8+ was fixed :/.

@jirislaby
Copy link
Contributor Author

@jirislaby jirislaby commented Nov 20, 2016

3.7 received that as a backport:

commit db381065aa57bcade0264dd8fdebf039adf0de8a
Author: Hans Wennborg <hans@hanshq.net>
Date:   Mon Aug 17 20:22:50 2015 +0000

    Merging r245064:
    ------------------------------------------------------------------------
    r245064 | cbieneman | 2015-08-14 09:20:31 -0700 (Fri, 14 Aug 2015) | 5 lines

    [CMake] Fix PR14200, llvm-config output misses -fno-rtti
@delcypher
Copy link
Contributor

@delcypher delcypher commented Nov 20, 2016

In principle you should be able to use the find_package(LLVM CONFIG) method for getting information from LLVM for LLVM 3.5 and newer

https://github.com/llvm-mirror/llvm/blob/release_35/cmake/modules/LLVMConfig.cmake.in

so that would probably be the preferred way of interacting with newer LLVM versions if they were built with CMake.

@delcypher
Copy link
Contributor

@delcypher delcypher commented Nov 20, 2016

One possible solution is I could add a CMake option to force RTTI of ( a sort of "I know what I'm doing flag") which you could use.

It's not ideal though. In principle we'd need one for disable exception handling too.

@jirislaby
Copy link
Contributor Author

@jirislaby jirislaby commented Nov 20, 2016

It's not about me, I backported the patch to llvm, so everything should be green for me... But for others, the flag would work.

@jirislaby
Copy link
Contributor Author

@jirislaby jirislaby commented Nov 20, 2016

Given we do not need dynamic_cast and other slow crap, what prevents us from disabling rtti in klee completely? (Independently on llvm.)

@jirislaby
Copy link
Contributor Author

@jirislaby jirislaby commented Nov 20, 2016

Or doesn't llvm-rtti + klee-no-rtti combination fly?

@delcypher
Copy link
Contributor

@delcypher delcypher commented Nov 20, 2016

@jirislaby I've never really used that combination (side note: I know that the LLVM packages in some distros build with RTTI enabled - e.g. Ubuntu/Debian).

I tried quickly now and it "seems to work" (just using Z3 and STP solvers).

For exceptions though we have to enable them for MetaSMT when that's enabled. Otherwise exceptions are disabled if they were disabled when LLVM was built.

I'm not sure if MetaSMT needs RTTI.

@pirapira
Copy link

@pirapira pirapira commented Mar 23, 2017

I hit the same problem, following http://klee.github.io/build-llvm34/

@delcypher
Copy link
Contributor

@delcypher delcypher commented Mar 23, 2017

@pirapira This does not help very much. From above you can see the reason for the problem in @jirislaby 's case. If your scenario is exactly the same as his then you can follow his approach to solve this.

If your scenario is different you need to explain exactly what you did. Giving a link to http://klee.github.io/build-llvm34/ doesn't tell me anything because the build works following those instructions on my system, on macOS and in our Docker container.

@pirapira
Copy link

@pirapira pirapira commented Mar 23, 2017

Yes, @jirislaby's approach worked for me.

@ccadar ccadar added the build system label Jul 21, 2017
@lukeZhangMengxi
Copy link

@lukeZhangMengxi lukeZhangMengxi commented Jul 28, 2017

Hi, I am quite new to this kind of stuff. I got the following errors when I try to make KLEE.
Is this a similar problem?
I tried adding "CXXFLAGS="-fno-rtti"" when I did the cmake, but I got the same errors.

[ 92%] Linking CXX executable ../../bin/kleaver
../../lib/libkleaverSolver.a(FastCexSolver.cpp.o): In function `propogateValues(klee::Query const&, CexData&, bool, bool&) [clone .constprop.147]':
/home/luke/intstalled-packages/klee/klee/lib/Solver/FastCexSolver.cpp:1012: undefined reference to `llvm::DebugFlag'
/home/luke/intstalled-packages/klee/klee/lib/Solver/FastCexSolver.cpp:1012: undefined reference to `llvm::isCurrentDebugType(char const*)'
../../lib/libkleaverSolver.a(FastCexSolver.cpp.o): In function `CexData::propogatePossibleValues(klee::ref<klee::Expr>, ValueRange)':
/home/luke/intstalled-packages/klee/klee/lib/Solver/FastCexSolver.cpp:444: undefined reference to `llvm::DebugFlag'
/home/luke/intstalled-packages/klee/klee/lib/Solver/FastCexSolver.cpp:444: undefined reference to `llvm::isCurrentDebugType(char const*)'
../../lib/libkleaverSolver.a(IndependentSolver.cpp.o): In function `getIndependentConstraints(klee::Query const&, std::vector<klee::ref<klee::Expr>, std::allocator<klee::ref<klee::Expr> > >&) [clone .constprop.314]':
/home/luke/intstalled-packages/klee/klee/lib/Solver/IndependentSolver.cpp:353: undefined reference to `llvm::DebugFlag'
/home/luke/intstalled-packages/klee/klee/lib/Solver/IndependentSolver.cpp:353: undefined reference to `llvm::isCurrentDebugType(char const*)'
collect2: error: ld returned 1 exit status
tools/kleaver/CMakeFiles/kleaver.dir/build.make:105: recipe for target 'bin/kleaver' failed
make[2]: *** [bin/kleaver] Error 1
CMakeFiles/Makefile2:688: recipe for target 'tools/kleaver/CMakeFiles/kleaver.dir/all' failed
make[1]: *** [tools/kleaver/CMakeFiles/kleaver.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2
@delcypher
Copy link
Contributor

@delcypher delcypher commented Jul 28, 2017

@lukeZhangMengxi

/home/luke/intstalled-packages/klee/klee/lib/Solver/FastCexSolver.cpp:1012: undefined reference to `llvm::DebugFlag'

This message is related to some internal debugging features in LLVM that we use. I don't think this is related to RTTI. Please open a new issue with more details information about your environment.

@MartinNowack
Copy link
Contributor

@MartinNowack MartinNowack commented Jul 12, 2018

Let's close this one:

  • Documentation is up-to-date and explicitly warns to not build LLVM 3.4 with cmake.
  • Travis with Docker builds LLVM up to 3.7 with autoconf and uses cmake starting from 3.8
  • We build RTTI and non-RTTI versions to test the general case

Thanks for all the input.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.