<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Kris,<div><br></div><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">I've been trying to find a way in through ObjectFile/RTDyldObjectLinkingLayer but have been stymied by the latter's sole focus on in-memory binaries (I believe, but I'm a C++ dunce).<br>So RuntimeDyld/Jitlink  do have the facility to load binary formats from disk?</blockquote></div><div><br></div><div>Short answer: Yes.</div><div><br></div><div>RuntimeDyld and JITLink both perform the same task: They take a buffer containing a relocatable object and apply the relocations to produce ready-to-use code for a target process (often the same process). They don't really care where the buffer comes from: In MCJIT and ORC it's usually produced directly in memory by compiling LLVM IR, but you can just as easily mmap a relocatable object file off disk. In fact, both RuntimeDyld and JITLink have testing tools that do exactly that: llvm/tools/llvm-rtdyld and llvm/tools/llvm-jitlink. If you have built clang and llvm-rtdyld you can run the following:</div><div><br></div><div><font face="monospace">% clang -c -o foo.o foo.c</font></div><div><font face="monospace">% llvm-rtdyld foo.o</font></div><div><br></div><div>The llvm-rtdyld tool will mmap foo.o, apply RuntimeDyld to it to resolve relocations, then execute the resulting fixed-up code to run the program in foo.c.</div><div><br></div><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">The Jitlink patch talks about 'dead stripping' - would that cover the reloading of an object file overwriting the previous set of symbols?<br>Or is there a way to unambiguously declare a set of symbols void and have Jitlink auto-reclaim the memory of the corresponding object file that supplied them?</blockquote></div><div><br></div><div>Both systems allow you to dispose of the relocated memory for an input file but neither provide built-in support for replacing definitions. It's possible to enable replacement of definitions with some manual work, but there are many possible approaches depending on your use-case. As an example: If you just want to replace function definitions (not data definitions) and don't care about performance you can just emit stubs (e.g. using <a href="http://llvm.org/doxygen/classllvm_1_1orc_1_1IndirectStubsManager.html">http://llvm.org/doxygen/classllvm_1_1orc_1_1IndirectStubsManager.html</a>) and then update these when you load new definitions.</div><div><br></div><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">The Jitlink patch talks about 'dead stripping' - would that cover the reloading of an object file overwriting the previous set of symbols?</blockquote></div><div><br></div><div>Dead stripping doesn't have much to do with code replacement. It is the removal of unused symbols. For example: if your relocatable object file provides a weak definition of "foo" but a strong definition already exists then the weak definition of foo is effectively unreferenced, so JITLink will dead-strip it. This may cause other definitions to also become unused so they will be dead-stripped too, and so on.</div><div><br></div><div>Regards,</div><div>Lang.</div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 20, 2020 at 8:40 AM kris <<a href="mailto:cq.personal@gmail.com">cq.personal@gmail.com</a>> wrote:<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">Hi Lang/Dave,<br>
<br>
I'm up and running with one of the other examples and will await that<br>
tree-landing for the WithObjectLinkingLayer one to build. hopefully!<br>
<br>
I've been trying to find a way in through ObjectFile/RTDyldObjectLinkingLayer<br>
but have been stymied by the latter's sole focus on in-memory binaries<br>
(I believe, but I'm a<br>
C++ dunce).<br>
So RuntimeDyld/Jitlink  do have the facility to load binary formats from disk?<br>
<br>
The Jitlink patch talks about 'dead stripping' - would that cover the<br>
reloading of an object file<br>
overwriting the previous set of symbols?<br>
Or is there a way to unambiguously declare a set of symbols void and<br>
have Jitlink auto-reclaim the memory of the corresponding object file<br>
that supplied them?<br>
<br>
thanks a lot.<br>
<br>
On 19/05/2020, Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>> wrote:<br>
> Hi Kris,<br>
><br>
> Dave is right: You'll want to check out ORC and JITLink. As a starting<br>
> point I'd recommend taking a look at this example that uses a JITLink<br>
> plugin to render the JIT-linker's graph data structure:<br>
> <a href="https://github.com/llvm/llvm-project/blob/master/llvm/examples/OrcV2Examples/LLJITWithObjectLinkingLayerPlugin/LLJITWithObjectLinkingLayerPlugin.cpp" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/blob/master/llvm/examples/OrcV2Examples/LLJITWithObjectLinkingLayerPlugin/LLJITWithObjectLinkingLayerPlugin.cpp</a><br>
><br>
> JITLink is currently only available on Darwin, but someone just posted a<br>
> review for an under-development ELF version: I expect that to land in-tree<br>
> this week and quickly develop enough relocation support to handle basic use<br>
> cases.<br>
><br>
> Regards,<br>
> Lang.<br>
><br>
> On Mon, May 18, 2020 at 7:45 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
><br>
>> Sounds like you're probably after ORC <a href="https://llvm.org/docs/ORCv2.html" rel="noreferrer" target="_blank">https://llvm.org/docs/ORCv2.html</a> -<br>
>> a JIT infrastructure, which as you've described, models object files and<br>
>> executable code in-memory as closely as possible to the on-disk format,<br>
>> and<br>
>> supports things like replaceable code.<br>
>><br>
>> On Mon, May 18, 2020 at 6:25 PM kris via llvm-dev<br>
>> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
>> wrote:<br>
>><br>
>>> hello folks,<br>
>>><br>
>>> I'm working to add runtime updating of code to the OCaml compiler<br>
>>> which in its bytecode<br>
>>> guise presents no barrier because there is only one linker and it is<br>
>>> written in that language and<br>
>>> full control is available.<br>
>>> With native code on the other hand, there is reliance on the system<br>
>>> linker and I got completely<br>
>>> lost examining the GNU ld/dl library source code.<br>
>>> The prospect of understanding and modifying all possible linkers is<br>
>>> daunting to say the least.<br>
>>> It's finally dawned on me that LLVM might have some of what I need<br>
>>> already.<br>
>>> Would you be kind enough to examine the following wish-list and<br>
>>> comment on it's current viability<br>
>>> with respect to the LLD project?<br>
>>><br>
>>> 1. to load and link a set of object/archive files into an in-memory<br>
>>> executable.<br>
>>> 2. to track the memory allocations attributable to each contributing<br>
>>> object processed with a view to releasing them.<br>
>>> 3. to maintain the symtable in-memory with a view to updating symbols<br>
>>> and re-patching the in-memory executable.<br>
>>> 4. to reload an object file/archive member (or a new one) and process<br>
>>> it in accordance with 3.<br>
>>><br>
>>> No doubt LLD is not geared to any of this directly, but does the<br>
>>> library provide any support?<br>
>>> thanks in advance....<br>
>>> _______________________________________________<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="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>>><br>
>><br>
><br>
</blockquote></div></div>