similar to: [LLVMdev] problem with execution engine on windows

"Viktar Zviarovich" <Viktar.Zviarovich at brunel.ac.uk> writes: [snip] > The function I am trying to call is trivial (took it from the tutorial > just for testing purposes) and has C calling conventions. The > execution engine returned by ExecutionEngine::create is Interpreter. > > Am I doing something wrong or is it a bug? Are you using CMake for generating the

"Viktar Zviarovich" <Viktar.Zviarovich at brunel.ac.uk> writes: > The suggested patch enables addition of all subdirectories of > llvm/projects to CMake build. > > It somewhat simplifies the process of creating new projects that use > CMake instead of make, eliminating the need of editing > llvm/CMakeLists.txt and llvm/projects/CMakeLists.txt. This is not

Hi Óscar, Thank you for the reply. I indeed got an impression (may be incorrect) that projects/ directory is intended for users' projects that are not committed to LLVM repository. Otherwise, of course, the patch doesn't make much sense. Anyway, I've added a comment about the need of explicit CMake invocation to projects/CMakeLists.txt. Thanks, Victor -----Original Message-----

Sorry, attached the wrong patch last time. ________________________________ From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Viktar Zviarovich Sent: 04 March 2009 14:19 To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] automatic discovery of new CMake projects Hi all, The suggested patch enables addition of all subdirectories of llvm/projects to

Hi all, The suggested patch enables addition of all subdirectories of llvm/projects to CMake build. It somewhat simplifies the process of creating new projects that use CMake instead of make, eliminating the need of editing llvm/CMakeLists.txt and llvm/projects/CMakeLists.txt. Best regards, Victor -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Tue, Oct 6, 2009 at 5:49 PM, Reid Kleckner <rnk at mit.edu> wrote: >> Also, the null pointer is coming from a call to JCE->allocateSpace(). >> This is a virtual function; I'm trying to discover what subclass it >> is. > > So, there's JITEmitter::allocateSpace which overrides > JITCodeEmitter::allocateSpace(), but *most* of the time it just calls >

> > It just occurred to me... in the case where it's failing, the > ExecutionEngine was trying to JIT a global, and it had never JITted > any functions!  I'll work up a small test case, but I think it's > relevant since the thing is trying to allocate the globals with the > functions. > That was it! The following small test program crashes in getPointerToGlobal:

> 6. When ExecutionEngine::create was called with parameter > "GVsWithCode" set to its default value of true, I got a segfault when > trying to get a pointer to one of my globals.  JIT::getMemoryForGV was > returning NULL in that case.  Explicitly passing false for > "GVsWithCode" cleared it up. That's no good. Could you send me a stack trace and explain

Hi, I'm on Linux and trying to link an application that makes use of LLVM's JIT execution engine statically. Setup: (1) LLVM libs are compiled as static libraries. (2) Called InitializeNativeTarget(). (3) Included llvm/ExecutionEngine/JIT.h. It works if I build and link regularly. However, if I add -static when linking, the execution engine fails to initialize. Does anyone know why?

Yeah, this is a problem with the static constructor getting optimized out. Including "JIT.h" is supposed to fix that. Is it possible that the file where you are including "JIT.h" doesn't have any required code in it? -Andy -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Mario Schwalbe Sent: Tuesday,

On Tue, Oct 6, 2009 at 4:15 PM, Reid Kleckner <rnk at mit.edu> wrote: >> 6. When ExecutionEngine::create was called with parameter >> "GVsWithCode" set to its default value of true, I got a segfault when >> trying to get a pointer to one of my globals.  JIT::getMemoryForGV was >> returning NULL in that case.  Explicitly passing false for >>

My front-end is humming along beautifully now with the LLVM trunk. A few upgrade notes for anyone who is interested: 1. Not surprisingly, everything in your front-end needs to be recompiled; object layouts have changed. My generated code was calling some name-mangled stuff in the C++ libraries, and using struct/class definitions defined therein, and it fell over hard when I ran it against the

Hi, guys. Have a strange problem with LLVM in my project ( https://github.com/ababo/AntOS). Cannot instantiate JIT execution engine (NULL returns; message: Interpreter has not been linked in.). As you can see from the code I call InitializeNativeTarget. Also I tried to directly include the "llvm/ExecutionEngine/JIT.h" header, but with no success. I link with `llvm-config --ldflags

Isn't there someone to help me with this issue? I'm very upset about this stupid problem which wasted the whole day. BTW, I can create JIT from main.cpp, but not in the required source file (runtime.cpp), so this is not about linking. Very weird. 2011/9/2 Semion Prihodko <semion.ababo at gmail.com> > I cannot call the constructor explicitly, because ForceJITLinking is a name

Hi, I'm having an issue with the below modules. I build module X, then module Y (which has a dependency on X). I've added an external declaration on module Y of the functions defined in X. i also link the except-handling module, but i think it is peripheral to the issue i like all the modules together in a single module called executableModule. I link them with the method:

Óscar Fuentes wrote: > 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 >>>>

On Mon, Oct 5, 2009 at 8:27 PM, Axel Naumann <Axel.Naumann at cern.ch> wrote: > Hi, > > #include "JIT.h" will do. Thanks. That was exactly what I needed to progress to the next error ("Unable to find target for this triple (no targets are registered)") As soon as I get this front-end working with the trunk, I'll start submitting patches that add calls to

I see two problems in your code 1) you need to #include "llvm/ExecutionEngine/JIT.h" 2) you must pass an empty string to EngineBuilder::setErrorStr. See JIT::createJIT for the reason. Jeff On Sat, Sep 3, 2011 at 8:33 AM, Semion Prihodko <semion.ababo at gmail.com> wrote: > Isn't there someone to help me with this issue? I'm very upset about this > stupid problem

>> 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

On Tue, Oct 6, 2009 at 2:39 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > My front-end is humming along beautifully now with the LLVM trunk.  A > few upgrade notes for anyone who is interested: > > 1. Not surprisingly, everything in your front-end needs to be > recompiled; object layouts have changed.  My generated code was > calling some name-mangled stuff in the