search for: allocatedatasect

...t *allocateCodeSection(uintptr_t Size, unsigned Alignment, unsigned SectionID) { return mgr()->allocateCodeSection(Size, Alignment, SectionID); } #if HAVE_LLVM >= 0x0303 virtual uint8_t *allocateDataSection(uintptr_t Size, unsigned Alignment, unsigned SectionID, bool IsReadOnly) { return mgr()->allocateDataSection(Size, Alignment, SectionID,...

...ntptr_t Size, > unsigned Alignment, > unsigned SectionID) { > return mgr()->allocateCodeSection(Size, Alignment, SectionID); > } > #if HAVE_LLVM >= 0x0303 > virtual uint8_t *allocateDataSection(uintptr_t Size, > unsigned Alignment, > unsigned SectionID, > bool IsReadOnly) { > return mgr()->allocateDataSection(Size, Alignment, SectionID, &g...

...unsigned Alignment, >> unsigned SectionID) { >> return mgr()->allocateCodeSection(Size, Alignment, SectionID); >> } >> #if HAVE_LLVM >= 0x0303 >> virtual uint8_t *allocateDataSection(uintptr_t Size, >> unsigned Alignment, >> unsigned SectionID, >> bool IsReadOnly) { >> return mgr()->allocateDataSection(Size, Alignmen...

...ve them to disk and in later sessions reload them. (2) How would I pass an ObjectFile saved in question#1 back to ORC so that it will relocate it and generate function pointers? (3) How do I get access to the relocated ObjectFile sections? Currently I subclass SectionMemoryManager and implement allocateDataSection(...) I can get the memory for the "__llvm_stackmaps" section - but I don't know when/if the contents have been fully set up with relocated function pointers. (4) For the "__llvm_stackmaps" section - will I need to do any relocation to obtain the function pointers? Ba...

...llvm-dev: > I think I found the answer to #3 and #4. > (a) I overloaded the SectionMemoryManager::finalizeMemory(...) method.  > (b) I first call the base classes method (maybe not necessary). > (c) At this point the __llvm_stackmaps section that I saved in thread > local memory when allocateDataSection was called appears to be fully > set up and relocated. > > > On Mon, Nov 5, 2018 at 12:36 PM Christian Schafmeister > <meister at temple.edu <mailto:meister at temple.edu>> wrote: > > I have a few questions about the new ORC JIT. > > I saw Lang Hame...

LLVM3.8 version. https://bugs.llvm.org//show_bug.cgi?id=24233. The example can catch exception. But I use my own code for testing, CustomEHMemoryManager allocated memory address is very large, allocateCodeSection, allocateDataSection assigned address (more than 32 bit address space) is getting smaller and smaller. Cause registerEHFrames to fail. 3.9.1 or 4.0.0 version has been supported on win x64? Or how to solve this problem? haifeng.qin at wellintech.com 发件人： haifeng.qin at wellintech.com 发送时间： 2017-02-17 10:38 收件人：...

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 "notifyObjectLoaded" is invoked, I allocate the shared memory - I'm getting the size from the local non-shared memory - and apply the address mapping. When the function "f...

...on. I've read the documentation of stackmap and found this paragraph: "A JIT compiler can easily access this section by providing its own memory manager via the LLVM C API LLVMCreateSimpleMCJITMemoryManager(). When creating the memory manager, the JIT provides a callback: LLVMMemoryManagerAllocateDataSectionCallback(). When LLVM creates this section, it invokes the callback and passes the section name. The JIT can record the in-memory address of the section at this time and later parse it to recover the stack map data. On Darwin, the stack map section name is "__llvm_stackmaps". The segme...

...target process. But perhaps I'm missing something regarding your particular scenario. > In any event, there are good reasons why a memory manager (particularly for local use) might want to know the total size before allocation begins. We subclass RTDyldMemoryManager interface to implement allocateDataSection and allocateCodeSection. As you know, when RuntimeDyld loads a module, it calls one of these methods for each section. I want that all sections of a module are allocated in one block. One reason is efficiency, another is that 32-bit relocations fail when the blocks are too far from each other....

Hi Matt, Philip, You could get the data you want by recording the addresses returned by the allocateCodeSection and allocateDataSection methods on your RTDyldMemoryManager, then disassembling those sections after you've called resolveRelocations. That's a little unsatisfying though. For one thing, unless you very carefully maintain the association with the original object via back-channels there will be no way of knowing...

For help: Llvm generated instruction calls a function (extern), the function will have a SEH exception (EXCEPTION_ACCESS_VIOLATION), But JIT can not capture the exception of the EXCEPTION_ACCESS_VIOLATION. I saw Bug 24233. EXCEPTION_ACCESS_VIOLATION exception cannot be captured after modification. How to catch EXCEPTION_ACCESS_VIOLATION exceptions on win64 ? haifeng.qin at wellintech.com

...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 "*notifyObjectLoaded*" is invoked, I allocate the >>> shared memory - I'm getting the size from the local non-shar...

>> To increase stability for us we have already moved the main part of the compilation to a separate process that may crash in case of an error without doing much harm, i.e. does not crash the database. > Were there any interesting challenges that arose during this process? > This seems to be an approach many folks are either taking or > considering. If there are things we could

...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 allocateDataSection method: 1) I collect pointers to objc-related sections for which the memory is allocated. Before SectionMemoryManager::finalizeMemory() method is called I register the ObjC runtime classes. 2) I iterate over __objc_selrefs sections and fixup selectors. This does fix the original crash of this t...

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

...easy way to do it per-function) by using a custom memory manager, rather than SectionMemoryManager. There are two ways to go about this: (1) The easy way (only valid for shared-memory on the same machine) is to allocate the sections directly out of shared memory (by overriding allocateCodeSection/allocateDataSection). (2) The hard way (which is general enough to allow you to copy the relocated bytes to remote machines) is three part: (a) Allocate the sections locally (e.g. using malloc, or inheriting from SectionMemoryManager and capturing the allocation details) (b) Override the notifyObjectLoaded metho...

...acking 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 allocateDataSection method: > > 1) I collect pointers to objc-related sections for which the memory is > allocated. Before SectionMemoryManager::finalizeMemory() method is > called I register the ObjC runtime classes. > 2) I iterate over __objc_selrefs sections and fixup selectors. This > does fix...

Great stuff; thanks both! I'm also looking to turn my MCJIT conversion spike into our main use case. The only thing I'm missing is the ability to get a post-linked copy of the generated assembly. In JIT I used JITEventListener's NotifyFunctionEmitted and used a MCDisassembler to disassemble the stream (with my own custom annotators), and redirected the output to the relevant place

...inalizeLoad() { + // Allocate the GOT if necessary + size_t numGOTEntries = GOTEntries.size(); + if (numGOTEntries != 0) { + // Allocate memory for the section + unsigned SectionID = Sections.size(); + size_t TotalSize = numGOTEntries * getGOTEntrySize(); + uint8_t *Addr = MemMgr->allocateDataSection(TotalSize, getGOTEntrySize(), + SectionID, false); + if (!Addr) + report_fatal_error("Unable to allocate memory for GOT!"); + Sections.push_back(SectionEntry(".got", Addr, TotalSize, 0)); + // For now, initialize al...

> On 13 Feb 2018, at 17:42, Stanislav Pankevich <s.pankevich at gmail.com> wrote: > > On Tue, Feb 13, 2018 at 12:18 PM, David Chisnall > <David.Chisnall at cl.cam.ac.uk> wrote: >> On 12 Feb 2018, at 22:31, Stanislav Pankevich via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> Specifically I explored the latest objc4-723 >>>