[PATCH] D58704: Initial (incomplete) implementation of JITLink - A replacement for RuntimeDyld.

Lang Hames via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 4 08:42:18 PST 2019


lhames added a comment.

In D58704#1415690 <https://reviews.llvm.org/D58704#1415690>, @ruiu wrote:

> In D58704#1415399 <https://reviews.llvm.org/D58704#1415399>, @kparzysz wrote:
>
> > Since you're rewrite this, is there any potential for sharing code with lld?  Relocating instructions should essentially be the same between these two.
>
>
> I haven't read this patch, but as a general comment, I could say that a static linker is fairly different from a JIT linker...


Actually they’ve got much more in common than you would think. The commonality comes from the input format: relocatable object files. The JIT linker does indeed need to create GOT entries, PLTs, etc. It is the output formats that are really different: A static linker needs to be able to output its data structures as executables, shared objects, or relocatable object files, which requires some non-trivial formatting. A JIT linker just needs to arrange the atom contents into memory segments with the right permissions. The other big differences are that the JIT linker only links one relocatable object file at a time (at least for now), and that it requires some asynchronous callbacks to make it efficient to use within the concurrent JIT APIs.

I did think about using the atom-based LLD for this, but it’s a big dependence to bring in to LLVM, and lacked the asynchronous API support that the JIT needed. In the end I opted for a cut down initial design inspired by the atom-based LLD.

In D58704#1415711 <https://reviews.llvm.org/D58704#1415711>, @ruiu wrote:

> In D58704#1415706 <https://reviews.llvm.org/D58704#1415706>, @kparzysz wrote:
>
> > I was actually thinking about handling of target-specific relocations, and applying them to instructions.  We used to have a large chunk of auto-generated code that did that.  The implementation in lld is much shorter, so it's probably not a big deal if it needs to be repeated.
>
>
> Yeah, applying a target-specific relocation is essentially just one line of code per a relocation type in lld, and given that the types of relocations that a JIT linker has to handle is more limited than a static linker, the duplication is pretty limited.


As noted, we actually do need to handle the full scope of relocations supported by the static linker (on the input side). There is not a lot of duplication to eliminate, but I’m thinking about switching to a named function for each relocation expression to support sharing between JITLink and its test infrastructure.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58704/new/

https://reviews.llvm.org/D58704





More information about the llvm-commits mailing list