search for: mcjitmemorymanag

...setup, it gets a bit farther and crashes rather than issuing that error. (Rebuilding with debugging symbols now to dig into it further…) -matt Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 0x000000010000349e in llvm::MCJITMemoryManager::startFunctionBody () (gdb) where #0 0x000000010000349e in llvm::MCJITMemoryManager::startFunctionBody () #1 0x0000000100003ea0 in llvm::RuntimeDyldImpl::extractFunction () #2 0x00000001000059a5 in llvm::RuntimeDyldMachO::loadSegment64 () #3 0x000000010000493d in llvm::RuntimeDyldMachO::loadO...

...ction is owned by the JITMemoryManager which was used in creating the ExecutionEngine. In the case of the legacy JIT engine, the JITMemoryManager is owned by the JITEmitter which in turn is owned by the JIT ExecutionEngine. In the case of the new MCJIT engine, the JITMemoryManager is owned by the MCJITMemoryManager which in turn is owned by the MCJIT ExecutionEngine. In either case, deleting the ExecutionEngine should result in the JITMemoryManager being deleted and therefore also the memory in which the JITed functions are contained. I think it's entirely possible that you just aren't seeing a pr...

Given: typedef MyClass* (*jit_fn_ptr_type)(); MyClass* set_fn( llvm::Function *fn ) { // create an ExecutionEngine 'exec' ... jit_fn_ptr_type fn_ptr = (jit_fn_ptr_type)exec->getPointerToFunction( fn ); return fn_ptr(); } After I call getPointerToFunction() to obtain the pointer to the JIT'd function and fun the function (that will produce an instance of MyClass on the

...and crashes rather than issuing that error. (Rebuilding with debugging symbols now to dig into it further…) > > -matt > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 > 0x000000010000349e in llvm::MCJITMemoryManager::startFunctionBody () > (gdb) where > #0 0x000000010000349e in llvm::MCJITMemoryManager::startFunctionBody () > #1 0x0000000100003ea0 in llvm::RuntimeDyldImpl::extractFunction () > #2 0x00000001000059a5 in llvm::RuntimeDyldMachO::loadSegment64 () > #3 0x000000010000493d in llvm...

Ah, now that makes sense. Guess I was a little over-eager with my bugreport. Thanks! :) However, I am now running into the same Problem as Matt ("Target does not support MC emission!"). Best, Ralf Am 25.08.2011 19:32, schrieb Bruno Cardoso Lopes: > Hi Ralf, > > FYI, old JIT doesn't support AVX at all, no encoding info, etc... The > only way to use AVX+JIT is using

...he other set of functions. This is further complicated by the RuntimeDyldMemoryManager, which doesn't inherit from the JITMemoryManager but does share a subset of functions and is implemented as a wrapper around the client-supplied memory manager in the current MCJIT code. There's also an MCJITmemoryManager class which derives from RuntimeDyld and is used by MCJIT but isn't exposed to the client at all. I'd like to see this situation cleaned up as we move forward with a way for the client to specify an MCJITMemoryManager directly and a separation of the legacy memory manager interface from...

...he other set of functions. This is further complicated by the RuntimeDyldMemoryManager, which doesn't inherit from the JITMemoryManager but does share a subset of functions and is implemented as a wrapper around the client-supplied memory manager in the current MCJIT code. There's also an MCJITmemoryManager class which derives from RuntimeDyld and is used by MCJIT but isn't exposed to the client at all. I'd like to see this situation cleaned up as we move forward with a way for the client to specify an MCJITMemoryManager directly and a separation of the legacy memory manager interface from...

Thanks! Currently using MCJIT. But migration to ORC is on my TODO list. - Paweł On Thu, May 12, 2016 at 8:30 PM Lang Hames <lhames at gmail.com> wrote: > Hi Pawel, > > Option (1) and (3) are very similar, but using custom resolution (option > 3) guarantees that JIT'd code can't accidentally end up depending on > functions in your JIT that you didn't mean to

...he other set of functions. This is further complicated by the RuntimeDyldMemoryManager, which doesn't inherit from the JITMemoryManager but does share a subset of functions and is implemented as a wrapper around the client-supplied memory manager in the current MCJIT code. There's also an MCJITmemoryManager class which derives from RuntimeDyld and is used by MCJIT but isn't exposed to the client at all. > > I'd like to see this situation cleaned up as we move forward with a way for the client to specify an MCJITMemoryManager directly and a separation of the legacy memory manager inte...

Hi Ralf, FYI, old JIT doesn't support AVX at all, no encoding info, etc... The only way to use AVX+JIT is using MCJIT, which contains the correct encoding, but unfortunately the framework isn't good yet as the old one is. On Thu, Aug 25, 2011 at 10:12 AM, Ralf Karrenberg <Chareos at gmx.de> wrote: > Hi Matt, > > I am unsure about MCJIT, but I guess the problem is the same.

On Wed, Sep 25, 2013 at 19:23 +0000, you wrote: > OK, so in the old implementation you linked a module against the > archive before passing it to MCJIT? Yes, I used a Linker instance to link together a number of my own modules and a static library, and then get a single new LLVM module out of that to hand over to MCJIT. > I can think of a way to solve this inside MCJIT, but it is

I've always just hacked support for this in to the various JITs (for JuliaLang, in our debuginfo.cpp file), by setting the no-frame-pointer-optim flag in the IR, then creating and populating a dummy unwind description object in the .text section, and registering that dynamically. Some day I hope to actually just register the .pdata/.xdata sections with the unwinder. PDBs are a bit different