<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Kris,<br></div><div dir="ltr"><div><br></div><div>Dave is right: You'll want to check out ORC and JITLink. As a starting point I'd recommend taking a look at this example that uses a JITLink plugin to render the JIT-linker's graph data structure: <a href="https://github.com/llvm/llvm-project/blob/master/llvm/examples/OrcV2Examples/LLJITWithObjectLinkingLayerPlugin/LLJITWithObjectLinkingLayerPlugin.cpp">https://github.com/llvm/llvm-project/blob/master/llvm/examples/OrcV2Examples/LLJITWithObjectLinkingLayerPlugin/LLJITWithObjectLinkingLayerPlugin.cpp</a></div><div><br></div><div>JITLink is currently only available on Darwin, but someone just posted a review for an under-development ELF version: I expect that to land in-tree this week and quickly develop enough relocation support to handle basic use cases.</div><div><br></div><div>Regards,</div><div>Lang.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 18, 2020 at 7:45 PM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@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"><div dir="ltr">Sounds like you're probably after ORC <a href="https://llvm.org/docs/ORCv2.html" target="_blank">https://llvm.org/docs/ORCv2.html</a> - a JIT infrastructure, which as you've described, models object files and executable code in-memory as closely as possible to the on-disk format, and supports things like replaceable code.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 18, 2020 at 6:25 PM kris via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</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">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 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 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>
</blockquote></div>
</blockquote></div></div>