similar to: [LLVMdev] MCJIT finalizeObject output to use in external process

Aha. Thanks. Seems like I need to call mapSectionAddress with the target address. But how I copy the code? What function would I call? On Wed, Mar 25, 2015 at 4:32 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > Yes, that is one of the intended use models for MCJIT. > > > > If you look at the source for ‘lli’ you’ll find an option called > “remote-mcjit” which

No, I was asking how to extract the code from MCJIT, and you said it use a custom memory manager. When you say that I must treat each section as a block, do you mean that there is inter-block relative offsets need to be maintained? Or that when I get a section, I must copy it to target process memory as a one-shot contiguous block. If it's second, I think we're ok. On Wed, Mar 25, 2015

Thanks, Andy. I'm now thinking about the case where the generated code has references to memory addresses in the IR (the only case I suppose is call remoteProcessADDR). I know this is not LLVM specific but what happens when that ADDR changes due to process restart or different machine. I know this is the clients responsibility to put the right address in the call instruction, but generally

Hi all. I found some issue in implementation of finalizeObject function in MCJIT.cpp. If you look at the source code of the function, you can notice that machine code for second "owned" module will never be generated if it doesn't depend on the first one. More over it will cause a crash if entry point isn't in first module. Implementation of finalizeObject using for loop will

Hi Radek, Sorry for the delayed response. I haven't had time to check your analysis yet, but you're probably right: MCJIT's support for multiple modules in a single instance is patchy at best. Do you have a test case (e.g. an lli invocation) that triggers this bug, or is this something you discovered just by reading the code? Cheers, Lang. On Thu, Nov 13, 2014 at 8:46 AM, David

I'm trying to build LLVM on Android rather than the other way around! Really just to see if it can be done. I worked out the first problem (my code was written for the old JIT and I'd missed something in updating to the MCJIT to make it work on ARM). It still doesn't work, but at this point I have no idea why and it'll be a while before I get to look at it again: the Android

Is it possible to try your program on a non-Android Linux? It might make debugging a bit less painful. If you haven't updated to the trunk code recently, it's possible that calling finalizeObject more than once would cause a crash. The changes that introduced multiple module support should have fixed that issue. It might be useful to set breakpoints in the memory manager you are using.

Hi Bjoern, CCing cfg-dev (since that's where the conversation started) and llvm-dev (since it's relevant there). Do you know if there is a way to obtain the fully resolved obj-code? I > wanted to load the functions into a shared memory, but how? The only thing > I receive is a function pointer, but I don't know how large the function > 'behind' is. Even a call to

Am 04.06.2013 16:05, schrieb David Tweed: > | I am curious about JMM->invalidInstructionCache(), which I found in > | lli.cpp implementation. lli.cpp contains also call finalizeObject(), I > | just overlooked it. lli.cpp calls finalizeObject(), which calls > | applyPermissions, which in turn calls invalidateInstructionCache. So why > | lli.cpp does call

Hi all, I tried to modify Kaleidoscope Tutorial (toy.cpp from llvm/examples/Kaleidoscope/Chapter7, LLVM 3.3 release branch) in order to use MCJIT instead of JIT. I get segmentation fault when running toy.cpp with fibonacci example from the tutorial. My modified toy.cpp is in attachment and still works with JIT (when #define USE_MCJIT line is commented out). I read discussions regarding

On 26 November 2013 01:55, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > IMHO, tests may be suppressed with lit.local.cfg, only if; > They were disabled, but then re-enabled because they don't fail on normal build bots, but they do on self-host bots. So, I think this is a more serious issue than just MCJIT, I think this is a Clang miscompilation. I'll try on x86 to see

Hi Dmitri, You might want to try replacing the call to JMM->invalidInstructionCache() with a call to TheExecutionEngine->finalizeObject(). If you are getting a non-NULL pointer from getPointerToFunction but it crashes when you try to call it, that is most likely because the memory for the generated code has not been marked as executable. That happens inside finalizeObject, which also

Hi Andrew, Am 04.06.2013 02:13, schrieb Kaylor, Andrew: > Hi Dmitri, > > You might want to try replacing the call to JMM->invalidInstructionCache() with a call to TheExecutionEngine->finalizeObject(). If you are getting a non-NULL pointer from getPointerToFunction but it crashes when you try to call it, that is most likely because the memory for the generated code has not been

On 26 November 2013 19:05, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > I would also note that the failure isn’t actually in anything > MCJIT-specific. Aside from the fact that it seems to be clang-specific, > the code that is failing is specific to the lli remote implementation. > It’s not clear to me why it would fail under aggressive optimization with > clang,

Hi Dmitri, You're right. The lli code should be cleaned up. As David said, there was a time when the call to invalidate the instruction cache was necessary. It isn't necessary anymore. -Andy -----Original Message----- From: Dmitri Rubinstein [mailto:dmitri.rubinstein at googlemail.com] Sent: Tuesday, June 04, 2013 7:20 AM To: David Tweed Cc: Kaylor, Andrew; LLVM Dev Subject: Re:

I switched my Common Lisp compiler to use MCJIT on the weekend and ran into a weird problem compiling one particular function. It crashes with an EXC_BAD_ACCESS error in MCJIT::finalizeObject when calling processFDE. The weird part is that the function does not appear to do anything special and I've whittled it down to the minimum size that still causes the crash. If I remove even one

I'm trying to get MCJIT working but I get the following errors: Full-featured argument passing not supported yet! UNREACHABLE executed at MCJIT.cpp:322! I'm sure the first one will be a problem, but the second one prevents me from testing anything. I don't know how to fix the problem. My code works when using the non-MC JIT, and I added to my EngineBuilder: .setUseMCJIT(true)

Hi Christian, Thanks for sharing this. Yaron Keren has been investigating some problems in the EH frame registration code recently, and I think this may be related. It at least sounds similar to the type of variations in behavior based on code size that Yaron was seeing. -Andy -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of

That makes it more mysterious then since I am indeed only calling a main function. Perhaps I have to invoke it a different way. Here's my call I have now: auto main = linker->getModule()->getFunction( "main" ); std::vector<llvm::GenericValue> args(2); args[0].IntVal = llvm::APInt( platform::abi_int_size, 0 ); args[1].PointerVal = nullptr; llvm::GenericValue gv =

MCJIT::runFunction supports only main-style argument passing but not other cases like the JIT. These types of arguments will work: (int, char**, char**) (int, char**) (int) (void) The general case is not supported since it requires creating a small stub function, compiling and running it on the fly, supported by JIT but not MCJIT. However, with the supported calling sequences, you can probably