[PATCH] RuntimeDyldMachO should handle RIP-relative relocations correctly, and the corresponding tests should have coverage for this

[Daniel Dunbar]

On Tue, May 21, 2013 at 2:44 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> > As an aside, can you guys explain to me why MCJIT uses an OS-specific
> linker
> > convention for doing JIT linking?  Wouldn't it be better for the LLVM
> JIT to
> > have its own internal linking convention that is unrelated to ELF or
> MachO?
> > It seems like this would be less error-prone than having RuntimeDyld try
> to
> > reimplement the system's own relocation logic.  It also seems highly
> > unorthodox for a JIT to masquerade as if you did an AOT compile and then
> ran
> > the dynamic linker; it would be much easier to architect the JIT so that
> the
> > information needed for linking is represented in an object-oriented way
> > rather than a blob of bits that pretends to be an on-disk object file.
>
> When MCJIT was being designed there was some discussion about creating
> a MCJIT object format. I was not directly involved at the time, but
> Daniel might remember the rationale for going with native object
> formats.
>

Actually my original proposal was to use a custom object format. See:
  http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-November/036279.html

 - Daniel


>
> One advantaged is that the MC side is a bit simpler. We have one
> object format less to worry about (and test) and I think only windows
> has two object file formats (there is ELF when using the JIT).
>
> An interesting idea might be to plug the JIT at the ObjectWriter
> interface. It would get a "parsed" representation of the required
> fixups, external symbols, etc. I am not sure how much re factoring
> would be needed to make this work.
>
> A somewhat crazy idea on the other direction would be to move some
> bits of lld to the llvm repo so that MCJIT would be given native
> .dylib/.so/.dll files, which should be a lot easier to handle.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130521/2d08bdcc/attachment.html>