similar to: [LLVMdev] how to call the function in hosting code from JITted IR code..?

oh,I'm sorry to make such a stupid mistake...But I still have to tell the correct one still didnt make difference...so weird 2014-04-04 16:30 GMT+08:00 Anton Korobeynikov <anton at korobeynikov.info>: > Are you sure, that LLVMGetNamedFunction(m,"_a_outside_func") does not > return NULL? I believe it should be > LLVMGetNamedFunction(m,"a_outside_func") >

Hello I quite thank you for your advice,but I have to tell that it made no difference too calling "LLVMAddGlobalMapping(ee,LLVMGetNamedFunction(m,"_a_outside_func"),(void*)(&a_outside_func));". 2014-04-04 16:10 GMT+08:00 Anton Korobeynikov <anton at korobeynikov.info>: > Hello > > While there is a symbol in the object file, there is nothing like this >

Hi, I think I need to make a small change to the MCJit interface, and would like some feedback on what the most appropriate option would be. I'm working on LLILC (a jit for the CoreCLR built on MCJit, which creates one module for each MSIL method, containing the main function and zero or more EH handler functions extracted from the MSIL method). The CoreCLR requires the jit to notify it of

Hi, I have a IR file generated by Clang: ; ModuleID = 'test_load_lib.c' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f80:128:128-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32-S32" target triple = "i686-pc-mingw32" declare i32 @a_outside_func(i32) define i32 @test_func() { entry: %call = call i32

Hey Joseph, What Lang said made me wonder. Is it the right time for us (LLILC) to move to ORC? The long term plan was to go there but this could be our forcing function. -R From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Lang Hames Sent: Friday, May 29, 2015 2:23 PM To: Joseph Tremoulet Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] MCJit interface

I am just getting started with llvm. Here's code I am trying to compile: #include <stdio.h>#include "llvm/IR/LLVMContext.h"#include "llvm/IR/Module.h"#include "llvm/IR/IRBuilder.h" int main(){ llvm::LLVMContext& context = llvm::getGlobalContext(); llvm::Module* module = new llvm::Module("top", context); llvm::IRBuilder<>

Hello, I'm replacing a struct with another struct of a different size. A problem arises when the following line occurs in the source code: MyStruct *a = malloc(sizeof(a)); The 'sizeof(a)' is turned into a constant in the LLVM IR, resulting in the wrong amount of memory being allocated for the struct. Is there any way to find all the constants that have arisen from sizeof? Thanks,

Hi Joseph, There are several reasons that a client might want to access the object before it's loaded, so a general API like #2 seems like the way to go. To support this in MCJIT you can add this to the event listener API. Orc clients can already do this by adding a custom object-file layer. - Lang. On Fri, May 29, 2015 at 9:05 AM, Joseph Tremoulet <jotrem at microsoft.com> wrote:

Hi all, So I’m also working on LLILC. Specifically, I have been working on a JITEventListener to pass debug line info to the CoreCLR EE. With Joe’s change, I’ve lost the ability (or as far as I can tell) to attach an event listener. Is there a way within Orc to do the sorts of things that the JITEventListeners do in MCJIT? How would I go about adding a layer to add debugging support? Thanks,

Agreed, that sounds like the best plan. I'll look into moving LLILC to ORC. Thanks -Joseph From: Russell Hadley Sent: Friday, May 29, 2015 8:13 PM To: Lang Hames; Joseph Tremoulet Cc: llvmdev at cs.uiuc.edu Subject: RE: [LLVMdev] MCJit interface question Hey Joseph, What Lang said made me wonder. Is it the right time for us (LLILC) to move to ORC? The long term plan was to go there but

When we were using MCJIT, I could do this: // Attach the event listener Context.EE->RegisterJITEventListener( LLILCJitEventListener::createLLILCJitEventListener( new LLILCJitEventWrapper(&Context))); The event listeners listened for when an object is emitted (NotifyObjectEmitted), and that’s when we’d go through and extract debug info from the ObjectFile. Now, I imagine

Hi LLVM folks, Attached with this email, you will find a patch not directly applicable (it doesn't compile like this) which (try to) enhance the structure of a possible JIT with the MC framework. Basically : - MCJIT : - Main class implementing ExecutionEngine interface - owns and creates : - a MemoryManager (will be a reuse of the JITMemoryManager mechanism) - a MCJITStreamer

On Mon, Jun 29, 2009 at 5:50 PM, Dale Johannesen<dalej at apple.com> wrote: > > On Jun 29, 2009, at 5:41 PMPDT, Reid Kleckner wrote: > >> So I (think I) found a bug in the JIT: >> http://llvm.org/bugs/show_bug.cgi?id=4483 >> >> Basically, globals used by a function are allocated in the same buffer >> as the first code that uses it.  However, when you

I've attached a patch which has got JIT compilation working (for me at least!) on Android. It turns out that the problem was a bunch of intrinsic __aeabi* functions which reside in libgcc.a rather than libc.so so are not available unless explicitly linked in, so it's rather similar to the StatSymbols hack. I moved the StatSymbols code into ExecutionEngine.cpp rather than

Hi All, I'm going to be making some API breaking changes to the ORC APIs, and to the RuntimeDyld class (which underlies MCJIT). The changes may affect MCJIT clients but are unlikely to. Where they do the fixes are likely to be trivial. ORC clients will be affected, but the fixes should also be straightforward. I have three upcoming changes in mind: 1) RuntimeDyld (the linker underlying

On 11/11/13 17:42, Kaylor, Andrew wrote: > I've got a number of problems with this patch. > > First, we have plans to pry apart the remaining strands connecting JIT with MCJIT, so I don't want to do anything that reconnects them. That is, I'm against moving things from RTDyldMemoryManager into ExecutionEngine. The direction of LLVM is not something I'm in a position to

Is there documentation somewhere on how to call external functions from llvm? The only guide I found was this: http://www.gearleaf.com/blog/post/44, and it doesn't seem to be working for me. I have a function: llvm::GenericValue lle_X_create_number_object(llvm::FunctionType* ft, const std::vector<llvm::GenericValue>& args) { llvm_object_structure* result = new

On Jun 29, 2009, at 5:41 PMPDT, Reid Kleckner wrote: > So I (think I) found a bug in the JIT: > http://llvm.org/bugs/show_bug.cgi?id=4483 > > Basically, globals used by a function are allocated in the same buffer > as the first code that uses it. However, when you free the machine > code, you also free the memory holding the global's data. The address > is still in the

Hi, All I got a linkage error as indicated in the subject line. Any suggestion? I created a call builder.CreateCall2(foo, p1, p2) in a module. foo is a Function* generated by module->getOrInsertFunction("foo", prototype). foo is defined outside of this module, and in the dump of the module, I see "declare i64 @foo(xxx, xxx)". The error happens during link time, it seems

I've got a number of problems with this patch. First, we have plans to pry apart the remaining strands connecting JIT with MCJIT, so I don't want to do anything that reconnects them. That is, I'm against moving things from RTDyldMemoryManager into ExecutionEngine. Second, unless I'm reading it wrong, this relies on static constructors. That causes headaches and is against the