[llvm-dev] linker adaptability ...

[Lang Hames via llvm-dev]

Hi Kris,

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:
https://github.com/llvm/llvm-project/blob/master/llvm/examples/OrcV2Examples/LLJITWithObjectLinkingLayerPlugin/LLJITWithObjectLinkingLayerPlugin.cpp

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.

Regards,
Lang.

On Mon, May 18, 2020 at 7:45 PM David Blaikie <dblaikie at gmail.com> wrote:

> Sounds like you're probably after ORC https://llvm.org/docs/ORCv2.html -
> 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.
>
> On Mon, May 18, 2020 at 6:25 PM kris via llvm-dev <llvm-dev at lists.llvm.org>
> wrote:
>
>> hello folks,
>>
>> I'm working to add runtime updating of code to the OCaml compiler
>> which in its bytecode
>> guise presents no barrier because there is only one linker and it is
>> written in that language and
>> full control is available.
>> With native code on the other hand, there is reliance on the system
>> linker and I got completely
>> lost examining the GNU ld/dl library source code.
>> The prospect of understanding and modifying all possible linkers is
>> daunting to say the least.
>> It's finally dawned on me that LLVM might have some of what I need
>> already.
>> Would you be kind enough to examine the following wish-list and
>> comment on it's current viability
>> with respect to the LLD project?
>>
>> 1. to load and link a set of object/archive files into an in-memory
>> executable.
>> 2. to track the memory allocations attributable to each contributing
>> object processed with a view to releasing them.
>> 3. to maintain the symtable in-memory with a view to updating symbols
>> and re-patching the in-memory executable.
>> 4. to reload an object file/archive member (or a new one) and process
>> it in accordance with 3.
>>
>> No doubt LLD is not geared to any of this directly, but does the
>> library provide any support?
>> thanks in advance....
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200519/472feb35/attachment.html>