search for: mapsectionaddress

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...

...awn at gmail.com] > *Sent:* Wednesday, March 25, 2015 5:00 PM > *To:* Kaylor, Andrew > *Cc:* LLVM Developers Mailing List > *Subject:* Re: [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 t...

...s are within 2GB of one another, but how > you meet this requirement is at your discretion. Apart from that, MCJIT > will take care of applying relocations to account for the relative location > of each section in the remote process according to the addresses you > provided in calls to mapSectionAddress. > > > > Another thing your custom memory manager may need to do that I forgot to > mention is handle linking of external functions needed by the generated > code. For in-process execution MCJIT will automatically link to things > like standard library functions that it recogn...

A need has arisen to generate code using MCJIT but not in the target process instead in a different process (and possibly even different machine though not in the scope). Reading through the tutorials and MCJIT design document, it seems like this is possible or was kept in mind during design of MCJIT. How do I achieve this? Are there examples? Dave -------------- next part -------------- An

Dear All I need to read the stackmap section at runtime of the inspected application. 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:

...The biggest one is that we "install" code into a different > location from where it was compiled.) > Can you clarify what you mean by "install" here? As it stands in the patch, Orc already supports cross-target and out-of-process JITing. The ObjectLinkingLayer exposes the mapSectionAddress call for mapping sections to new locations, and the MCJITReplacement demo passes all remote-jitting regression tests on Darwin. The intent is that Orc should eventually provide a superset of the functionality provided by MCJIT, but with the various features broken out into separate components. I...

...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 method to allocate the final memory locations, then call RTDyldMemoryManager::mapSectionAddress to map each local allocation to its corresponding final address (c) Override finalizeMemory to copy the relocated bytes to their final addresses Hope this helps. Cheers, Lang. On Tue, May 2, 2017 at 10:47 PM, <bjoern.gaier at horiba.com> wrote: > Hello Lang, > > your answer...

...ration process has roughly 5 steps: 0. Generate and optimize LLVM IR. 1. Call generateCodeForModule on the output of (0) to translate LLVM IR to machine code. 2. Figure out the final locations for the code and data generated by MCJIT using an allocator specific to our runtime. Make mapSectionAddress calls to convey this information to MCJIT. 3. Call finalizeObject() to apply relocations. 4. Copy over the relocated code to buffers allocated by our custom allocator. The problem: After running step (1) we may, in rare cases, decide that the generated code is not usable by our runtime [*]...

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

Agreed, that sounds like the best plan. I'll look into moving LLILC to ORC. Thanks -Joseph From: Russell Hadley Sent: Friday, May 29, 2015 8:13 PM To: Lang Hames; Joseph Tremoulet Cc: llvmdev at cs.uiuc.edu Subject: RE: [LLVMdev] MCJit interface question Hey Joseph, What Lang said made me wonder. Is it the right time for us (LLILC) to move to ORC? The long term plan was to go there but

Hi All, The attached patch (against r225842) contains some new JIT APIs that I've been working on. I'm going to start breaking it up, tidying it up, and submitting patches to llvm-commits soon, but while I'm working on that I thought I'd put the whole patch out for the curious to start playing around with and/or commenting on. The aim of these new APIs is to cleanly support a