similar to: [LLVMdev] Resolving a function symbol using JIT.

Hi Andrew, I used the latest code from trunk. GlobalSymbolTable is being used in MCJIT. I guess it wasn't clear from the proposal that the user program will be modified to indicate that the callback should happen at that point in the code. The objective is to call some of the functions which belong to lli or the ExecutionEngine. Thanks, Sumeeth On Fri, Nov 1, 2013 at 5:40 PM, Kaylor,

Unless I'm missing something, indeed addGlobalMapping should not work with MCJIT. MCJIT does not consult EEState.getGlobalAddressMap when resolving symbols. Instead it uses RTDyldMemoryManager::getSymbolAddress which checks with DynamicLibrary::SearchForAddressOfSymbol, so Andy's suggestion of DynamicLibrary::addSymbol is better as it should work with both JIT and MCJIT. Another options

Hello, I would like to have your opinions on this. *Problem:* Currently, there are no ways to perform hypercalls into LLVM (they transfer execution from the program being executed to the LLVM infrastructure to perform compilation). The goal of this project is to cleanly integrate an API into the LLVM code/execution engine to create custom callbacks. The “lli” executable should allow having a

Hi all, I am new to LLVM so I apologize if my question seem lame to you. I was trying to understand the way in which MCJIT generates the stub functions when it encounters any functions which are not compiled yet. As far as I have looked into the code, the probable code which can do this is void *JIT::getPointerToFunctionOrStub and this is in JITEmitter under JIT. I may be wrong here though.

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Kaylor, Andrew > Subject: Re: [LLVMdev] [Proposal] Adding callback mechanism to Execution Engines > If the function is in a statically linked module, you need to do something to explicitly expose it. With > the older JIT engine you can use addGlobalMapping as Yaron suggests, but I

Are you using the latest code from trunk? I didn't think the latest code used the address mapping in the ExecutionEngine base class. Of course, if people are depending on this it might be something that should be fixed if it isn't working. -Andy From: Caldarale, Charles R [mailto:Chuck.Caldarale at unisys.com] Sent: Friday, November 01, 2013 10:54 AM To: Kaylor, Andrew; sumeeth kc;

On Thu, Oct 31, 2013 at 11:39 PM, sumeeth kc <sumeethkc at gmail.com> wrote: > Hello, > > I would like to have your opinions on this. > > *Problem:* > > Currently, there are no ways to perform hypercalls into LLVM (they > transfer execution from the program being executed to the LLVM > infrastructure to perform compilation). The goal of this project is to >

Hey Everyone, I understood this a little differently (well, I do have direct contact with Sumeeth given that we both work in the same lab). Allow me to try and explain his proposal. We are trying to optimise out instructions from a program (JIT-compiled OS Kernels or JIT-compiled Web Server code) during run time and we have this hypothesis that some of the decisions are best taken by the

On Sat, 2005-08-27 at 11:47 -0700, Reid Spencer wrote: > Alkis Evlogimenos wrote: > > It seems that these two classes are the same... Maybe they should be > > merged into 1 class? > > > I think you're looking at something old. MutexLocker doesn't exist any more. llvm/Support/ThreadSupport.h is not generated anymore? -- Alkis

Hi Sumeeth, I'm not sure I understand what your new mechanism is supposed to add. You can already call functions defined in the host program from generated code. The Kaleidoscope tutorial does this. If the function you want to call is defined in a module that is dynamically loaded and you are using the default memory manager all you need to do is declare a prototype for the function in

It seems that these two classes are the same... Maybe they should be merged into 1 class? -- Alkis

Alkis Evlogimenos wrote: > It seems that these two classes are the same... Maybe they should be > merged into 1 class? > I think you're looking at something old. MutexLocker doesn't exist any more. Reid.

Hi James, > want to send us your testcase code? Then we can give it a whirl. > > > Test code is at http://giantblob.com/ehtest.tar.gz > > Thanks for the help. I apologize in advance if it turns out I'm doing > something stupid! I hope you realise that by running llvm-ld without -native you are actually executing your program from the JIT. I did a native

Hi all, I need to run c++ prgrams using lli. However, I find lli cannot handle the alias instruction correctly. Following is an example: ------------ example.cc ------------- #include <iostream> using namespace std; class cls { public: cls(); ~cls(); }; cls::cls() { cout << "constructor" << endl; }; cls::~cls() { cout <<

Hi Everyone, When I compile a program with clang with debug symbols enabled and I try to run it using the JIT (lli) I get the following error message. I am running on Lion (10.7.4). Thanks. George >> pseudo instructions should be removed before code emission UNREACHABLE executed at /Users/JD/Software/llvm3.1/llvm-3.1.src/lib/Target/X86/X86CodeEmitter.cpp:736! 0 lli

2010/1/22 Duncan Sands <baldrick at free.fr> > Hi James, > > > want to send us your testcase code? Then we can give it a whirl. >> >> >> Test code is at http://giantblob.com/ehtest.tar.gz >> >> Thanks for the help. I apologize in advance if it turns out I'm doing >> something stupid! >> > > I hope you realise that by

2010/1/22 James Williams <junk at giantblob.com> > > > 2010/1/22 Duncan Sands <baldrick at free.fr> > >> Hi James, >> >> >> want to send us your testcase code? Then we can give it a whirl. >>> >>> >>> Test code is at http://giantblob.com/ehtest.tar.gz >>> >>> Thanks for the help. I apologize in

Hi, I've been implementing a compiler that targets LLVM, and was looking into using the shadow-stack gc strategy. Currently, I build the runtime with clang (using -emit-llvm), and then link that with the LLVM bitcode output from my compiler using llvm-ld. This works fine without the gc strategy annotations and use of the llvm.gcroot intrinsic, but adding them causes some odd behavior: the

Forgot to CC the list. ----- Forwarded Message ---- > From: Samuel Crow <samuraileumas at yahoo.com> > To: Trevor Elliott <trevor at galois.com> > Sent: Fri, January 14, 2011 7:33:15 PM > Subject: Re: [LLVMdev] LLVM GC > > Hi Trevor, > > Are you linking with LibStdC++ or LibC++? That is a requirement for running > code that has been compiled from C++

Hi James, Note that the wiki example is a manual JIT example that works directly with the C++ APIs. As you know, no LLVM tools are used, just LLVM libraries. I say this to point out, that in the example, the exception mechanism is under the complete control of the developer moded by the LLVM libraries. In my mind a different example/different doc. would be needed to explain how a bit code