<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Bjoern,<div><br></div><div>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.</div><div><br></div><div>There is no easy way to do this for multiple object files. I think you would have to mimic the memory size calculations performed by RuntimeDyld, then pre-allocate the memory yourself.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">BUT... There is one problem. The shared memory can't be dynamical adjusted. So if I add another module to the current module, then I would go through this process again! Not the "finalizeMemory" process though, but I would allocate another shared memory. This is not what I want! Currently I use the linker first, to work around this problem, but this will not help me if I add object files or libraries to the JIT process - or does it?</blockquote><div><br></div><div>Unless all of your code is pre-compiled (i.e. you can calculate the required allocations up-front) I do not think this can be avoided. I think the best you can do is conservatively over-allocate shared memory in the hope that you do not end up needing to make a second allocation.</div><div><br></div><div>Cheers,</div><div>Lang.</div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 7, 2018 at 11:12 PM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">And then I used reply instead of reply-all... I'm on a roll. Added llvm-dev back again... So maybe this is right now. Maybe - sorry for the confusion <br><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 7, 2018, 11:11 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Well I meant to add him but failed. Cc'd him here now :)<br><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 7, 2018, 10:41 PM Gaier, Bjoern <<a href="mailto:Bjoern.Gaier@horiba.com" target="_blank">Bjoern.Gaier@horiba.com</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div lang="EN-US" link="blue" vlink="purple">

<div class="m_700402520877933195m_4510333608569834496m_8383481122365384504WordSection1">

<p class="MsoNormal">Is… Lang now added? I’m not sure about this system…<br>

<br>

My problem is that I can not change the size of the shared memory I’m targeting – so I can only allocate it once, but how do I know how much memory I’m going to need, when each sections requests the memory after each other?<br>

To work around this I first allocate the memory locally and count the bytes it needed. After notifyObjectLoaded I can request the shared memory and do the mapping. But this only covers one module. If I have two modules for example, then I will end up having

 two shared memories, because the second module will go through the same steps as the first one. But I want to have one coherent memory.<u></u><u></u></p>

<p class="MsoNormal"><u></u> <u></u></p>

<p class="MsoNormal">Also the applying of the mapping causes a bug with the new LLVM7 – I already filled out a bug report for this. But I have no idea how things will progress from that point… Still I have no idea about the system…<u></u><u></u></p>

<p class="MsoNormal"><u></u> <u></u></p>

<p class="MsoNormal"><b>From:</b> David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> <br>

<b>Sent:</b> Mittwoch, 7. November 2018 17:34<br>

<b>To:</b> Gaier, Bjoern <<a href="mailto:Bjoern.Gaier@horiba.com" target="_blank">Bjoern.Gaier@horiba.com</a>><br>

<b>Cc:</b> llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>

<b>Subject:</b> Re: [llvm-dev] JIT-Client for Shared Memory<u></u><u></u></p></div></div><div lang="EN-US" link="blue" vlink="purple"><div class="m_700402520877933195m_4510333608569834496m_8383481122365384504WordSection1">

<p class="MsoNormal"><u></u> <u></u></p>

<div>

<p class="MsoNormal" style="margin-bottom:12.0pt">Adding Lang here in case he's got some insight.<br>

<br>

I take it the system you're targeting doesn't have the memory limitations that some systems have, where once memory is set executable, it can never be written to? & so you'd like to write some code into a page, execute it, write some more code into the same

 page and have that execute too?<br>

<br>

(I don't know teh JIT architecture well enough to know if that's supported, or if I'm accurately understanding your situation, etc)<u></u><u></u></p>

<div>

<div>

<p class="MsoNormal">On Thu, Nov 1, 2018 at 11:49 PM Gaier, Bjoern via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>

</div>

<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">

<div>

<div>

<p class="MsoNormal">Hello everyone,<u></u><u></u></p>

<p class="MsoNormal"> <u></u><u></u></p>

<p class="MsoNormal">I want to use the LLVM to write a JIT client, that works with shared memory. Currently I proceed as following:<u></u><u></u></p>

<p class="MsoNormal"> <u></u><u></u></p>

<p class="MsoNormal">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.<u></u><u></u></p>

<p class="MsoNormal">When the function "<i>notifyObjectLoaded</i>" is invoked, I allocate the shared memory - I'm getting the size from the local non-shared memory - and apply the address mapping.<u></u><u></u></p>

<p class="MsoNormal">When the function "finalizeMemory" is invoked I copy the code from the local non-shared memory to the shared memory but only one time.

<u></u><u></u></p>

<p class="MsoNormal"> <u></u><u></u></p>

<p class="MsoNormal">So far so good, this works actually good! Yippie x3<u></u><u></u></p>

<p class="MsoNormal"> <u></u><u></u></p>

<p class="MsoNormal">BUT... There is one problem. The shared memory can't be dynamical adjusted. So if I add another module to the current module, then I would go through this process again! Not the

 "<i>finalizeMemory</i>" process though, but I would allocate another shared memory. This is not what I want! Currently I use the linker first, to work around this problem, but this will not help me if I add object files or libraries to the JIT process - or

 does it?<u></u><u></u></p>

<p class="MsoNormal"> <u></u><u></u></p>

<p class="MsoNormal">So is there any way to work around this?<u></u><u></u></p>

<p class="MsoNormal"> <u></u><u></u></p>

<p class="MsoNormal">Kind greetings<u></u><u></u></p>

<p class="MsoNormal">Björn<u></u><u></u></p>

</div>

<p class="MsoNormal">Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, USt.ID-Nr. DE 114 165 789 Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert Plank, Markus Bode, Heiko Lampert, Takashi Nagano, Takeshi Fukushima. Junichi Tajika

<u></u><u></u></p>

</div>

<p class="MsoNormal">_______________________________________________<br>

LLVM Developers mailing list<br>

<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>

<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><u></u><u></u></p>

</blockquote>

</div>

</div>

</div>

Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, USt.ID-Nr. DE 114 165 789 Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert Plank, Markus Bode, Heiko Lampert, Takashi Nagano, Takeshi Fukushima. Junichi Tajika

</div>

</blockquote></div>

</blockquote></div>

</blockquote></div>