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

[Jim Grosbach]

The really short version is that a JIT infrastructure for LLVM is going to need to be able to interact with the surrounding platform environment in a lot of ways. The platform’s native object file format is already tailored to do exactly that, in exactly the places the MCJIT needs, so rather than reinvent the wheel, we just used what we already have. The debugger and profiler interfaces are great examples of the sort of the sorts of things I mean.

Now, it would probably be even better to go all the way to the shared library format instead of stopping at the object file, but that’s a problem that hasn’t yet been tackled. Eventually I’d like there to be stronger cooperation with the platform shared library manager, when such exists, on the target.

-Jim

On May 21, 2013, at 5:08 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote:

> The decision to use ELF and MachO predates my involvement, but I can tell you that having those formats makes cooperation with other tools (such as debuggers and profilers) a lot easier.
> 
> -Andy
> 
> -----Original Message-----
> From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Rafael Espíndola
> Sent: Tuesday, May 21, 2013 2:44 PM
> To: Filip Pizlo
> Cc: llvm-commits at cs.uiuc.edu
> Subject: Re: [PATCH] RuntimeDyldMachO should handle RIP-relative relocations correctly, and the corresponding tests should have coverage for this
> 
>> 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.
> 
> 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
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130524/bf100b31/attachment.html>