similar to: [LLVMdev] 2.6/trunk Execution Engine question

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

Hi, #include "JIT.h" will do. Cheers, Axel. On 2009-10-06 03:09, Kenneth Uildriks wrote: > I've gotten my front-end to compile with the 2.6 branch and with trunk > (not with both; I have to fiddle with a few things when switching), > and it refuses to give me an execution engine. > > My link flags include everything coming from "llvm-config --libs". >

Hi Keno, The part that scares me a bit is > and then adjust the other methods to not > bail out two quickly when encountering a weak symbol. I would very much appreciate if you could implement this; I don't have enough knowledge of the MCJIT nor llvm CodeGen internals... I will happily try it out and provide you with feedback, though! :-) Thank you *so* much for your fast reaction!

Hi, we want to implement a C++ interpreter using LLVM and clang, to replace our existing one <http://root.cern.ch/drupal/content/cint> that is used as part of a data handling and analysis environment <http://root.cern.ch>. We plan to keep the set of features that our current interpreter offers, e.g. calls into and out of libraries, dynamic scoping, unloading of code, and a prompt. I

2009/8/31 Axel Naumann <Axel.Naumann at cern.ch>: > we want to implement a C++ interpreter using LLVM and clang Isn't clang going on that direction anyway? cheers, --renato Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm

Hi, is there an option to build LLVM's libs (and maybe clangs, but that's for later :-) as shared libraries? It's not --enable-shared :-) If it doesn't exist: is there any interest to have it? It would reduce my build time considerably... Cheers, Axel.

Hi, I'm finally moving cling to MCJIT - and MCJIT is wonderful! So far I only ran into this issue: $ cat linkonceodr.cxx extern "C" int printf(const char*,...); template <class T> struct StaticStuff { static T s_data; }; template <class T> T StaticStuff<T>::s_data = 42; int compareAddr(int* mcjit); #ifdef BUILD_SHARED int compareAddr(int* mcjit) { if (mcjit

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

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

Hi, I ran into a problem migrating cling (finally!) to MCJIT: When an ("outer") MCJIT's finalization / llvm::RuntimeDyldImpl::resolveExternalSymbols() is called and a symbol is not known, cling can help by loading the suitable library and providing the symbol. It compiles the relevant C++ header as part of loading the library. This compilation emits symbols through the MCJIT. That

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 >

Hi, This is a question on how to resolve weak symbols from the binary for symbols that are also llvm::Module-local. Currently, the JIT seems to favor resolving to module-local symbols over existing symbols: $ cat symbols.cxx extern "C" int printf(const char*,...); template <class T> struct StaticStuff { static T s_data; }; template <class T> T

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

Axel Naumann <Axel.Naumann at cern.ch> writes: > is there an option to build LLVM's libs (and maybe clangs, but that's > for later :-) as shared libraries? It's not --enable-shared :-) If it > doesn't exist: is there any interest to have it? It would reduce my > build time considerably... With cmake it is BUILD_SHARED_LIBS http://www.llvm.org/docs/CMake.html

Hi Óscar, On 2009-10-08 00:49, Óscar Fuentes wrote: > Axel Naumann <Axel.Naumann at cern.ch> writes: >> is there an option to build LLVM's libs (and maybe clangs, but that's >> for later :-) as shared libraries? > > With cmake it is BUILD_SHARED_LIBS > > http://www.llvm.org/docs/CMake.html Great! So I must use CMake instead of configure / make to get

> 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

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

Hi, I've been trying to find a list of the current JIT-supported targets. Not easy :-) The sources seem to say that the architectures are X86, PowerPC, ARM, Alpha. And then their obvious combination with Linux, FreeBSD / MacOSX, Win32 - is that it? Cheers, Axel.

On Jan 20, 2009, at 5:56 AM, Axel Naumann wrote: > Hi, > > I've been trying to find a list of the current JIT-supported > targets. Not easy > :-) The sources seem to say that the architectures are X86, PowerPC, > ARM, > Alpha. And then their obvious combination with Linux, FreeBSD / > MacOSX, Win32 - > is that it? X86-64 and PPC64 also. I don't know how

On Thu, Nov 19, 2009 at 12:45 PM, Samuel Crow <samuraileumas at yahoo.com> wrote: > > > > > ----- Original Message ---- >> From: Kenneth Uildriks <kennethuil at gmail.com> >> To: Samuel Crow <samuraileumas at yahoo.com> >> Cc: OvermindDL1 <overminddl1 at gmail.com>; LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> >> Sent: