qemu build fails on wheezy x86_64

[smclinden]

I've built LLVM 3.3 according to the documentation (but not with the debug option). When I attempt to compile Panda I get the following:

• nproc
• make -j 1
  GEN config-host.h
  GEN trace.h
  GEN trace.c
  GEN config-target.h
  LINK x86_64-softmmu/qemu-system-x86_64
  ../slirp/misc.o: In function memset': /usr/include/x86_64-linux-gnu/bits/string3.h:82: warning: memset used with constant zero length parameter; this could be due to transposed parameters panda/panda_dynval_inst.o:(.data.rel.ro._ZTIN4llvm22PandaInstrFunctionPassE[_ZTIN4llvm22PandaInstrFunctionPassE]+0x10): undefined reference totypeinfo for llvm::FunctionPass'
  panda/panda_helper_call_morph.o:(.data.rel.ro._ZTIN4llvm26PandaCallMorphFunctionPassE[_ZTIN4llvm26PandaCallMorphFunctionPassE]+0x10): undefined reference to typeinfo for llvm::FunctionPass' tcg/tcg-llvm.o:(.data.rel.ro._ZTI17TJITMemoryManager[_ZTI17TJITMemoryManager]+0x10): undefined reference totypeinfo for llvm::SectionMemoryManager'
  collect2: error: ld returned 1 exit status
  make[1]: *** [qemu-system-x86_64] Error 1
  make: *** [subdir-x86_64-softmmu] Error 2

Suggestions?

[moyix]

Could you make sure that LLVM and QEMU were built with the same compiler?

Also, make sure that you're using the ./build.sh for QEMU.

[smclinden]

Yes to both. Same compiler and used the ./build.sh (but changed the path to the llvm build).

[smclinden]

64-bit Linux should not be a problem, right?

[jhodosh]

64-bit Linux is the only supported build environment.

[moyix]

I believe this is caused by building LLVM without RTTI support. Make sure that you have built LLVM using:

REQUIRES_RTTI=1 make

[smclinden]

That may be it. I believe that LLVM is built with -fno-rtti by default, though I may be incorrect about that.

[smclinden]

I checked and I actually cut and pasted this line from the Panda documentation:
CC=gcc-4.7 CXX=g++-4.7 ./configure --enable-optimized --disable-assertions --enable-targets=x86 && REQUIRES_RTTI=1 make -j $(nproc)

I also checked and build.sh uses version 4.7 for gcc and g++ so they are using the same compiler.

[moyix]

Well, I the only way to proceed now is to start checking low-level details. Since it's complaining about an undefined symbol, make sure the LLVM library you're linking to defines typeinfo for llvm::FunctionPass (it should be in libLLVMCore.a).

Mine looks like (the relevant line is the one with the "V"):

$ nm -C ../llvm-3.3/Release/lib/libLLVMCore.a | grep "typeinfo for llvm::FunctionPass"
                 U typeinfo for llvm::FunctionPass
0000000000000000 V typeinfo for llvm::FunctionPass
                 U typeinfo for llvm::FunctionPass
0000000000000000 V typeinfo for llvm::FunctionPassManager
0000000000000000 V typeinfo for llvm::FunctionPassManagerImpl
                 U typeinfo for llvm::FunctionPass
                 U typeinfo for llvm::FunctionPass

Also make sure the library you run nm on is actually the one you're linking to. If you do V=1 make &> compile.log in the qemu directory, you should at the end see a line like:

g++-4.7 -m64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE [... lots and lots snipped ...] -lLLVMTableGen -lLLVMDebugInfo -lLLVMOption -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMIRReader -lLLVMAsmParser -lLLVMMCDisassembler -lLLVMMCParser -lLLVMInstrumentation -lLLVMArchive -lLLVMBitReader -lLLVMInterpreter -lLLVMipo -lLLVMVectorize -lLLVMLinker -lLLVMBitWriter -lLLVMMCJIT -lLLVMJIT -lLLVMCodeGen -lLLVMObjCARCOpts -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMTarget -lLLVMMC -lLLVMObject -lLLVMCore -lLLVMSupport -L/scratch/git/panda/llvm-3.3/Release/lib [...]

The part at the end (-L/scratch/git/panda/llvm-3.3/Release/lib) is the path to LLVM QEMU is using.

Since ld is complaining, I would expect that the libLLVMCore.a you're linking against does not have the typeinfo for llvm::FunctionPass defined; your goal will be to figure out why that's happening and make sure it gets built with that symbol.

Unfortunately I can't be of much more help, since I can't reproduce this on my end.

[yrp604]

You're likely linking against llvm 3.4, which moved llvm::FunctionPass into llvm::legacy::FunctionPass. If you change the order of your include dirs (so 3.3 is first), it will probably work.