[llvm-dev] linker adaptability ...

[David Blaikie via llvm-dev]

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/20200518/674c6c84/attachment.html>