search for: finalizememori

Hi, I am studying the llvm code and I noticed something that looks like a bug. If it is intentional for some reason, it is not obvious why. In lib/ExecutionEngine/SectionMemoryManager.cpp in SectionMemoryManager::finalizeMemory method: // Make code memory executable. ec = applyMemoryGroupPermissions(CodeMem, sys::Memory::MF_READ | sys::Memory::MF_EXEC); ... //

On Saturday, 15 July 2017 05:46:35 CEST 陳韋任 wrote: > SectionMemoryManager allocates executable memory section for MCJIT > (JIT emit code then execute). > So the bottomline is making the section sys::Memory::MF_EXEC. As for > RODataMem, we also need > to make sure it's read-only. You can compare it to RWDataMem, which > has write permission. That makes sense. My question is

Hello everyone, I want to use the LLVM to write a JIT client, that works with shared memory. Currently I proceed as following: I wrote an own class that inherits "RTDyldMemoryManager". The functions "allocateCodeSection" and "allocateDataSection" are allocating local non-shared memory. I store there addresses in a std::vector. When the function

Hi Bjoern, For single object files you can override the needsToReserveAllocationSpace method that is inherited from llvm::RuntimeDyld::MemoryManager (make it return true) and then implement the reserveAllocationSpace method to allocate memory for all sections up front. There is no easy way to do this for multiple object files. I think you would have to mimic the memory size calculations

Hi Christian Your use case seems to have similar requirements as remote JITing in ORC. So far I haven't used that part myself and I am sure Lang can tell you much more about it. However, this comment on the RemoteObjectClientLayer class sounds promising for your questions (1) and (2): /// Sending relocatable objects to the server (rather than fully relocated /// bits) allows JIT'd code

Mesa (http://www.mesa3d.org/) uses LLVM to compile shaders. These are typically small bits of code (~10KB) and one application can use many of them. Mesa creates an ExecutionEngine with a default JIT memory manager for each shader it compiles, and keeps the engine around as long as the shader code is needed. This results in memory waste of ~1MB for each shader. Half the overhead is in the

Hi Frank, The project really needs to be looking to move away from the old JIT and to MCJIT. LLVM is actively working to kill the old JIT. It’s already unmaintained. MCJIT is the way forward. Can you elaborate on what’s blocking its adoption for Mesa? -Jim On Oct 1, 2013, at 10:44 AM, Frank Henigman <fjhenigman at google.com> wrote: > Mesa (http://www.mesa3d.org/) uses LLVM to compile

I'll try to find out, or get someone to explain, why Mesa selects MCJIT with LLVM 3.1 only and JIT for other LLVM versions. I'm not keen to code a fourth attempt (1: copy JIT code, 2: delegating manger, 3: derive from DefaultJITMemoryManager, 4: copy MCJIT code) but I'll try copying code with MCJIT. Is that the usual route for people who want to delete all LLVM engines, etc. while

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

Hi Lang, It turns out I also need an ability to tell the object linking layer not to apply any relocations. I need to skip this step below. The only way I can see I can achieve that is by creating my own ObjectLinkingLayer that would duplicate almost all of orc::ObjectLinkingLayer. I’d like to avoid that. An alternative it to pass a flag to orc::ObjectLinkingLayer constructor and

I have a few questions about the new ORC JIT. I saw Lang Hames (hi!) excellent talk at the llvm-dev meeting a few weeks ago. The ORC JIT is undergoing some API changes and I'd like/need to take advantage of them. (1) How do I take ownership of the ObjectFile once the ORC JIT has created it? I'd like to take ownership of object files generated by the ORC JIT so that I can save them to

Hi Eugene, Skipping the call to resolveRelocations would disable many (if not all) internal relocations too. Is that the desired behavior? At that point there's not much left for RuntimeDyld (or the ObjectLinkingLayer) to do. Would something like a NoopLinkingLayer be a workable solution? Cheers, Lang. On Wed, Jul 22, 2015 at 7:26 PM, Eugene Rozenfeld < Eugene.Rozenfeld at

Yes, I’m handling all internal and external relocations manually in NotifyLoadedFtor and I already verified that I get the behavior I need if I comment out the call to resolveRelocations. I would like to reuse ObjectLinkingLayer::addObjectSet (which eventually calls RuntimeDyld::loadObject), which has the right calls to the memory manager and also RuntimeDyld::registerEHFrames. I understand that

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

Hi Eugene, Sorry for the delayed reply. Custom relocations weren't something I had in mind when I designed Orc, so they raise some interesting design questions which I don't have good answers to yet. (E.g. The interface for the Orc layer concept assumes that there's a RuntimeDyld instance embedded at the bottom of the stack. That's why addModuleSet takes a MemoryManager and

Hi again, I had tried to follow David's suggestion to take a step back and look into codegen instead of hacking on RuntimeDyld but then I quickly realized that I don't understand what exactly needs to be done to fully register Objective-C runtime. I decided to iterate on JIT code again and somehow I found that I can hook into SectionMemory by subclassing it and working with its

Hi David, Stanislav, Sorry for the delayed reply. Short version: There hasn't been any progress on this just yet, as I have been busy with an overhaul of the underlying ORC APIs. 1) Hack up something in RuntimeDyldMachO to handle the data structures > currently generated by clang. This is fragile, because the interface > between the compiler and the runtime is not documented, and is

Hi Stanislav, Sorry -- I am not much help here. I would like to get ObjC runtime support for the JIT, but have not had time to look in to it closely. When I last tested the idea (a couple of years ago now) we used selector registration and objc_readClassPair to get basic test cases working as you have, but ran into (possibly similar) failures on non-trivial test cases. I think the interpretation

Hi Lang, Yes, I can return a non-zero marker value. Are you ok with this version? void RuntimeDyldImpl::resolveExternalSymbols() { while (!ExternalSymbolRelocations.empty()) { StringMap<RelocationList>::iterator i = ExternalSymbolRelocations.begin(); StringRef Name = i->first(); if (Name.size() == 0) { // This is an absolute symbol, use an address of zero.