search for: executionenginebind

...>>> Try adding this to the link command of your executable: >>> >>> /INCLUDE:_X86TargetMachineModule >>> >>> I should document this somehow. >>> >> Yeah, this is necessary, but not sufficient. I also had to link with >> ExecutionEngineBindings.obj (not JIT.obj as first stated) >> > > So you are using the C bindings. Okay, could someone advise what to do > here? Something like the _X86TargetMachineModule trick on > lib/Target/X86/X86TargetMachine.cpp line 26, but on > lib/ExecutionEngine/ExecutionEngineBindin...

...g this to the link command of your executable: >>>> >>>> /INCLUDE:_X86TargetMachineModule >>>> >>>> I should document this somehow. >>>> >>> Yeah, this is necessary, but not sufficient. I also had to link with >>> ExecutionEngineBindings.obj (not JIT.obj as first stated) >>> >> >> So you are using the C bindings. Okay, could someone advise what to do >> here? Something like the _X86TargetMachineModule trick on >> lib/Target/X86/X86TargetMachine.cpp line 26, but on >> lib/ExecutionEngi...

...o-long-long -Wno-maybe-uninitialized -Wno-comment -std=c++11 -g -Wl,-z,defs -shared -Wl,-soname,libLLVMExecutionEngine.so.3.7 -o lib/libLLVMExecutionEngine.so.3.7.0svn lib/ExecutionEngine/CMakeFiles/LLVMExecutionEngine.dir/ExecutionEngine.cpp.o lib/ExecutionEngine/CMakeFiles/LLVMExecutionEngine.dir/ExecutionEngineBindings.cpp.o lib/ExecutionEngine/CMakeFiles/LLVMExecutionEngine.dir/GDBRegistrationListener.cpp.o lib/ExecutionEngine/CMakeFiles/LLVMExecutionEngine.dir/SectionMemoryManager.cpp.o lib/ExecutionEngine/CMakeFiles/LLVMExecutionEngine.dir/TargetSelect.cpp.o lib/libLLVMCore.so.3.7.0svn lib/libLLVMMC.so.3....

...T.lib should suffice... a >> VC++ linker issue? >> > > Try adding this to the link command of your executable: > > /INCLUDE:_X86TargetMachineModule > > I should document this somehow. > Yeah, this is necessary, but not sufficient. I also had to link with ExecutionEngineBindings.obj (not JIT.obj as first stated) /Stein Roger

...t; VC++ linker issue? >>> >> >> Try adding this to the link command of your executable: >> >> /INCLUDE:_X86TargetMachineModule >> >> I should document this somehow. > > Yeah, this is necessary, but not sufficient. I also had to link with > ExecutionEngineBindings.obj (not JIT.obj as first stated) So you are using the C bindings. Okay, could someone advise what to do here? Something like the _X86TargetMachineModule trick on lib/Target/X86/X86TargetMachine.cpp line 26, but on lib/ExecutionEngine/ExecutionEngineBindings.cpp? Why is not the linker automat...

...gt;> >>>>> /INCLUDE:_X86TargetMachineModule >>>>> >>>>> I should document this somehow. >>>>> >>>>> >>>> Yeah, this is necessary, but not sufficient. I also had to link with >>>> ExecutionEngineBindings.obj (not JIT.obj as first stated) >>>> >>>> >>> So you are using the C bindings. Okay, could someone advise what to do >>> here? Something like the _X86TargetMachineModule trick on >>> lib/Target/X86/X86TargetMachine.cpp line 26,...

...ng this to the link command of your executable: > >>> > >>> /INCLUDE:_X86TargetMachineModule > >>> > >>> I should document this somehow. > >>> > >> Yeah, this is necessary, but not sufficient. I also had to link with > >> ExecutionEngineBindings.obj (not JIT.obj as first stated) > >> > > > > So you are using the C bindings. Okay, could someone advise what to do > > here? Something like the _X86TargetMachineModule trick on > > lib/Target/X86/X86TargetMachine.cpp line 26, but on > > lib/ExecutionEng...

...30== by 0xEAE543C: llvm::RuntimeDyldImpl::resolveRelocations() (RuntimeDyld.cpp:51) ==27130== by 0xEAE8236: llvm::RuntimeDyld::resolveRelocations() (RuntimeDyld.cpp:561) ==27130== by 0xA25EA99: llvm::MCJIT::finalizeObject() (MCJIT.cpp:173) ==27130== by 0xAB57918: LLVMGetPointerToGlobal (ExecutionEngineBindings.cpp:332) ==27130== by 0x4E4813D: compile_query (ql.c:2286) ==27130== by 0x4E4836A: tusto_ql_compile (ql.c:2322) ==27130== by 0x402D19: process_query (ts_util.c:167) ==27130== by 0x403205: run_shell (ts_util.c:296) I have source tree checked out at f46e5eadc307beaef6e8dd0602bb4c63ca...

...ntimeDyldImpl::resolveRelocations() > (RuntimeDyld.cpp:51) > ==27130== by 0xEAE8236: llvm::RuntimeDyld::resolveRelocations() > (RuntimeDyld.cpp:561) > ==27130== by 0xA25EA99: llvm::MCJIT::finalizeObject() (MCJIT.cpp:173) > ==27130== by 0xAB57918: LLVMGetPointerToGlobal > (ExecutionEngineBindings.cpp:332) > ==27130== by 0x4E4813D: compile_query (ql.c:2286) > ==27130== by 0x4E4836A: tusto_ql_compile (ql.c:2322) > ==27130== by 0x402D19: process_query (ts_util.c:167) > ==27130== by 0x403205: run_shell (ts_util.c:296) > > I have source tree checked out at f46e5...

...#0: 0x0000000102e00042 frame #1: 0x00000001015c01fb LLVMPlayGround`llvm::JIT::runFunction(llvm::Function*, std::vector<llvm::GenericValue, std::allocator<llvm::GenericValue> > const&) + 4747 at JIT.cpp:547 frame #2: 0x00000001015a0db2 LLVMPlayGround`LLVMRunFunction + 322 at ExecutionEngineBindings.cpp:195 frame #3: 0x0000000101096125 LLVMPlayGround`main + 741 at main.c:91 frame #4: 0x0000000101095e34 LLVMPlayGround`start + 52 Which looks to be in some non-c code. At least XCode cannot find any corresponding source: 0x102e00042: movl $10, (%rsp) <-- DIE 0x102e00049: movl...

srs <skaflotten at gmail.com> writes: > While testing my compiler on win32 in JIT mode, I ran into a couple of > issues: > > 1. I linked the compiler with the lib files resulting from the cmake > created VS.NET build. While everything built just fine, the > ExecutionEngine::create call always returned NULL. The fix was to also > link with JIT.obj (thanks aKor for

...#0: 0x0000000102e00042 frame #1: 0x00000001015c01fb LLVMPlayGround`llvm::JIT::runFunction(llvm::Function*, std::vector<llvm::GenericValue, std::allocator<llvm::GenericValue> > const&) + 4747 at JIT.cpp:547 frame #2: 0x00000001015a0db2 LLVMPlayGround`LLVMRunFunction + 322 at ExecutionEngineBindings.cpp:195 frame #3: 0x0000000101096125 LLVMPlayGround`main + 741 at main.c:91 frame #4: 0x0000000101095e34 LLVMPlayGround`start + 52 Which looks to be in some non-c code. At least XCode cannot find any corresponding source: 0x102e00042: movl $10, (%rsp) <-- DIE 0x102e00049: movl...

Hi all, While testing my compiler on win32 in JIT mode, I ran into a couple of issues: 1. I linked the compiler with the lib files resulting from the cmake created VS.NET build. While everything built just fine, the ExecutionEngine::create call always returned NULL. The fix was to also link with JIT.obj (thanks aKor for pointing me in the right direction). I would have thought that linking

...lease+Asserts build make[2]: Entering directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/Linker' llvm[2]: Compiling LinkModules.cpp for Release+Asserts build llvm[2]: Compiling EdgeBundles.cpp for Release+Asserts build llvm[2]: Compiling ErlangGC.cpp for Release+Asserts build llvm[2]: Compiling ExecutionEngineBindings.cpp for Release+Asserts build llvm[3]: Compiling GlobalDCE.cpp for Release+Asserts build llvm[2]: Building Release+Asserts Archive Library libLLVMLinker.a make[2]: Leaving directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/Linker' make[3]: Entering directory '/home/NIKHILREDDY/WORK/LLVM...