search for: applypermissions

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 JMM->invalidInstructionCache() explicitely again ? > > My suspicion is it's a historical development; because different > architectures do or don't actually require cache invalidation the calls have...

...ctionID); } #endif virtual void *getPointerToNamedFunction(const std::string &Name, bool AbortOnFailure=true) { return mgr()->getPointerToNamedFunction(Name, AbortOnFailure); } #if HAVE_LLVM == 0x0303 virtual bool applyPermissions(std::string *ErrMsg = 0) { return mgr()->applyPermissions(ErrMsg); } #elif HAVE_LLVM > 0x0303 virtual bool finalizeMemory(std::string *ErrMsg = 0) { return mgr()->finalizeMemory(ErrMsg); } #endif };

...> virtual void *getPointerToNamedFunction(const std::string &Name, > bool AbortOnFailure=true) { > return mgr()->getPointerToNamedFunction(Name, AbortOnFailure); > } > #if HAVE_LLVM == 0x0303 > virtual bool applyPermissions(std::string *ErrMsg = 0) { > return mgr()->applyPermissions(ErrMsg); > } > #elif HAVE_LLVM > 0x0303 > virtual bool finalizeMemory(std::string *ErrMsg = 0) { > return mgr()->finalizeMemory(ErrMsg); > } > #endif > }; > _______________...

...id *getPointerToNamedFunction(const std::string &Name, >> bool AbortOnFailure=true) { >> return mgr()->getPointerToNamedFunction(Name, AbortOnFailure); >> } >> #if HAVE_LLVM == 0x0303 >> virtual bool applyPermissions(std::string *ErrMsg = 0) { >> return mgr()->applyPermissions(ErrMsg); >> } >> #elif HAVE_LLVM > 0x0303 >> virtual bool finalizeMemory(std::string *ErrMsg = 0) { >> return mgr()->finalizeMemory(ErrMsg); >> } >> #endif...

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

...eidoscope Tutorial 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 JMM->invalidInstructionCache() explicitely again ? > > My suspicion is it's a historical development; because different > architectures do or don't actually require cache invalidation the > ca...

...;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[0] == '\1') ... When BaseName is empty...

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

...mitObject((Module*) F); finalizeObject(); return NULL; } FinalizeObject should not call resolveRelocations. Instead it should call the *new* clearRelocations. void MCJIT::finalizeObject() { // New Dyld call clearRelocations Dyld.clearRelocations(); // Set page permissions. MemMgr->applyPermissions(); } At the moment I am just leaking allocated sections in SMM. i.e. void MCJIT::freeMachineCodeForFunction(Function *F) { dbgs() << "free machine code not yet supported in MCJIT\n"; return; } But it should be relatively straight forward to maintain some kind of Module ->...

Hey Andy, Yep I've tested some non-trivial examples with loads of dependencies, both code and data, global, local and external symbol resolution etc.. Actually this was truly a piece of cake, nothing to do, the memory manager is working really nicely so far as I can tell. Relocations to sections are all working as expected (aside from previously mentioned ARM issue which is probably just