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 invalidates the code cache.
Thanks a lot, this helped. Now I just see "Error: redefinition of function" when I define new function, and this is expected.
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 JMM->invalidInstructionCache() explicitely again ?
Also I think there is a bug in MCJIT::getPointerToFunction:
StringRef BaseName = F->getName();
if (BaseName == '\1')
When BaseName is empty it triggers assertion. For example in Kaleidoscope tutorial an unnamed function is created.
Even so, this will likely only work in cases where code generation is only invoked once.
You are correct that MCJIT won't work in this case because of the function-by-function approach used in the Kaleidoscope example. Basically, with MCJIT once code has been generated for a module nothing else can be added to the Module.
Making Kaleidoscope work with MCJIT would require introducing some sort of scheme where a new module was created each time a new function was created. In the current implementation of MCJIT in trunk it is at least theoretically possible to make such a solution work by also creating a new instance of the MCJIT engine for each Module. It is our intention to enhance MCJIT to allow multiple modules to be handled by a single instance, but there would still be the requirement that once code was generated for a Module it couldn't be modified again. There may also be some work necessary in the memory manager to link the modules together.
When I correctly understand this multi-module incremental approach, I would need to create a new module for any new function generated. Since my new function will likely call another previously defined functions, I will need to declare them in the new module too. Their implementations already exist in the module(s) that I created in previous steps. And memory manager will take care of linking object code generated from all my incrementally created modules.
I am also using in my code ExecutionEngine::addGlobalMapping for defining functions that are declared in LLVM code but defined in my application. Will this work with MCJIT ?
Obviously it wouldn't be a trivial job to modify the Kaleidoscope example to work with MCJIT, but I think it should be possible.
I don't have a concrete time frame for when multiple module support will be available in MCJIT.
OK, I will try to make workarounds in my code as long as MCJIT does not support multi-module fully.