similar to: [LLVMdev] Dynamically loading native code generated from LLVM IR

Kaylor, do you have some good documented example code which shows the usage of the MCJIT ? This would help a lot ... the sematic of lots of API calls are not intuitively understandable. Best Regards --Armin Kaylor, Andrew wrote: > I'm not sure I understand your use case, but MCJIT (as opposed to the legacy JIT) does almost exactly what you're asking for. It generates an

Daniel, I didn't find the MCJIT directory under unitests/ExecutionEngine ... there is only a directory called JIT. You mean this directory ? Many thanks --Armin Malea, Daniel wrote: > Take a look at the MCJIT unit tests under unittests/ExecutionEngine/MCJIT > > The MCJITTestBase class does the majority of the interactions with the LLVM API you're referring to. > >

Take a look at the MCJIT unit tests under unittests/ExecutionEngine/MCJIT The MCJITTestBase class does the majority of the interactions with the LLVM API you're referring to. Good luck, Dan On 2012-10-13, at 4:57 AM, "Armin Steinhoff" <as at steinhoff-automation.com> wrote: > > Kaylor, > > do you have some good documented example code which shows the usage of

It's definitely there. It was added in r165246 recently so you probably have an older version. Amara On 13 October 2012 23:02, Armin Steinhoff <as at steinhoff-automation.com> wrote: > Daniel, > > I didn't find the MCJIT directory under unitests/ExecutionEngine ... there > is only a directory called JIT. > You mean this directory ? > > Many thanks > >

I'm not sure I understand your use case, but MCJIT (as opposed to the legacy JIT) does almost exactly what you're asking for. It generates an in-memory object file image (using addPassesToEmitMC) and then loads and links it for execution. If there's some particular detail you don't like in the way this is happening, you might be able to generate a file as you have and then use

Hi Baris, > If I could produce a .so file in step 1, my problem would be solved. llc has a "-relocation-model=pic" option, but the file produced with that did not dynamically load. That relocation-model=pic option usually necessary for a linker to be able to produce a .so file (it changes how variables are addressed so that more things can be decided when the .so is loaded), but it

On 12 Eki 2012, at 20:00, Jim Grosbach wrote: > > On Oct 12, 2012, at 7:07 AM, Baris Aktemur <baris.aktemur at ozyegin.edu.tr> wrote: > >> Dear Tim, >> >>> >>> The JIT sounds like it does almost exactly what you want. LLVM's JIT >>> isn't a classical lightweight, dynamic one like you'd see for >>> JavaScript or Java.

Dear Tim, > > The JIT sounds like it does almost exactly what you want. LLVM's JIT > isn't a classical lightweight, dynamic one like you'd see for > JavaScript or Java. All it really does is produce a native .o file in > memory, take care of the relocations for you and then jump into it (or > provide you with a function-pointer). Is there any other reason you >

On Oct 12, 2012, at 11:14 AM, Baris Aktemur <baris.aktemur at ozyegin.edu.tr> wrote: > > On 12 Eki 2012, at 20:00, Jim Grosbach wrote: > >> >> On Oct 12, 2012, at 7:07 AM, Baris Aktemur <baris.aktemur at ozyegin.edu.tr> wrote: >> >>> Dear Tim, >>> >>>> >>>> The JIT sounds like it does almost exactly what you

Dear Jim, On 12 Eki 2012, at 21:17, Jim Grosbach wrote: > > On Oct 12, 2012, at 11:14 AM, Baris Aktemur <baris.aktemur at ozyegin.edu.tr> wrote: > >> >> On 12 Eki 2012, at 20:00, Jim Grosbach wrote: >> >>> >>> On Oct 12, 2012, at 7:07 AM, Baris Aktemur <baris.aktemur at ozyegin.edu.tr> wrote: >>> >>>> Dear Tim,

I am generating LLVM IR code and I would like to convert this IR code to native code using the LLVM C++ API. This would be very similar to what's done in the Kaleidoscope tutorial, but instead of relying on JIT compilation, I'd like to emit native code -- the same native code that's produced by llc, for instance. I'm sure this is possible, but I wasn't able to find the

On Oct 12, 2012, at 7:07 AM, Baris Aktemur <baris.aktemur at ozyegin.edu.tr> wrote: > Dear Tim, > >> >> The JIT sounds like it does almost exactly what you want. LLVM's JIT >> isn't a classical lightweight, dynamic one like you'd see for >> JavaScript or Java. All it really does is produce a native .o file in >> memory, take care of the

On Thu, Sep 20, 2012 at 2:42 AM, Baris Aktemur <baris.aktemur at ozyegin.edu.tr> wrote: > I am generating LLVM IR code and I would like to convert this IR code to > native code using the LLVM C++ API. This would be very similar to what's > done in the Kaleidoscope tutorial, but instead of relying on JIT > compilation, I'd like to emit native code -- the same native code

Tim Northover wrote: > Hi Baris, > >> If I could produce a .so file in step 1, my problem would be solved. llc has a "-relocation-model=pic" option, but the file produced with that did not dynamically load. > That relocation-model=pic option usually necessary for a linker to be > able to produce a .so file (it changes how variables are addressed so > that more things

On Oct 22, 2012, at 11:34 AM, Jack Howarth wrote: > Nick, > I have uploaded the full walk with 'set env DYLD_PRINT_INITIALIZERS'. It didn't seem very informative > as the dyld error occurs right after... > > (gdb) > llvm::sys::DynamicLibrary::getPermanentLibrary (filename=0x142903da8 "/sw/opt/llvm-3.2/lib/LLVMPolly.so", errMsg=0x7fff5fbfe6e0) at

On Sun, Oct 21, 2012 at 06:00:36PM -0700, Nick Kledzik wrote: > Jack, > > Some binary has an initializer which dyld is calling. Somehow the initializer gets to: > #4 0x0000000100f3b2c0 in Json::Value::maxUInt () > which is calling a function in another dylib for the first time. When you call a function in another dylib, you actually jump through a (lazy) pointer. The pointer

On Mon, Oct 22, 2012 at 11:40:32AM -0700, Nick Kledzik wrote: > > On Oct 22, 2012, at 11:34 AM, Jack Howarth wrote: > > > Nick, > > I have uploaded the full walk with 'set env DYLD_PRINT_INITIALIZERS'. It didn't seem very informative > > as the dyld error occurs right after... > > > > (gdb) > >

On Oct 23, 2012, at 12:50 PM, Jack Howarth wrote: > On Mon, Oct 22, 2012 at 11:40:32AM -0700, Nick Kledzik wrote: >> >> On Oct 22, 2012, at 11:34 AM, Jack Howarth wrote: >> >>> Nick, >>> I have uploaded the full walk with 'set env DYLD_PRINT_INITIALIZERS'. It didn't seem very informative >>> as the dyld error occurs right after...

On Mon, Oct 22, 2012 at 09:48:59AM -0400, Jack Howarth wrote: > On Sun, Oct 21, 2012 at 06:00:36PM -0700, Nick Kledzik wrote: > > Jack, > > > > Some binary has an initializer which dyld is calling. Somehow the initializer gets to: > > #4 0x0000000100f3b2c0 in Json::Value::maxUInt () > > which is calling a function in another dylib for the first time. When you

Nick, While enhancing the fink llvm32 packaging to support the polly tool, I ran into a dyld failure when the dragonegg plugin tries to load LLVMPolly.so plugin... dyld: lazy symbol binding failed: fast lazy bind offset out of range (39257, max=7640) in image /sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.4.2/4.7.2/cc1 dyld: fast lazy bind offset out of range (39257, max=7640) in image