[llvm-commits] RuntimeDyLd new features

Kaylor, Andrew andrew.kaylor at intel.com
Wed Feb 8 16:55:43 PST 2012

Hi Danil,

Thanks for your efforts in this area.  As Eli Bendersky mentioned, we have a patch out for review in this area also.  I'm hopeful that we can find a convergence between our code, your code and the code that Jim Grosbach has put in place.

Unfortunately, we have been submitting our code in small chunks for ease of review and to keep things stable, and it may not be obvious from what we've put out for review what our intentions were or our intended solutions to the problems that were left open.  I'd like to take this opportunity to discuss the direction we we're heading and see how it might align with what you and Jim have done.

Let me first explain what we have done, and then I'll offer specific comments on your code and possible next steps.

We have had two primary goals: (1) to get MCJIT generated code to work correctly on Intel architecture and help pave the way for other implementations and (2) enable source-level debugging of JITed code with GDB.  This second goal seems to be dropping from view, but it places a few constraints on the eventual implementation.  We've had GDB integration working, BTW.

In order to get GDB to handle JITed code, we need to register an ELF object image through an interface GDB defines.  As you might expect, GDB has some peculiar expectations for what this ELF object image should look like.  In particular, we need to set a flag in the ELF header and update the sh_addr members in the section headers to reflect the address where the section contents reside in memory.

Our most recent patch (http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120130/135997.html, not yet committed) begins by copying the entire ELF image emitted by the MC code generator into an executable buffer.  This was intended as a temporary step toward our eventual solution.  It enabled us to perform relocations in-place on the object and execute functions in place (thus eliminating an extra copy that was previously being done).  We were in the process of implementing a smarter section-based approach, but Jim Grosbach was implementing a similar approach in parallel and our submission ended up appearing out of step in this regard.

So that's our background.  Now, returning to your patch....

I like the idea of combining as much common code as possible into the RuntimeDyldImpl class.  I'm interested to hear from users of the MachO loader if your implementation has lost any of the specialization that they need.  I think it's a promising approach.  There are some ELF-specific details that we will need to have incorporated to re-enable GDB integration, but I expect that we'll be able to find a way to work that in with a few well-placed overloaded function calls.

I have some reservations about the use of the basic ObjectFile interface, which has some serious limitations.  We've been working toward exposing the ELFObjectFile template for use in the runtime loading process (as well as other unrelated uses).  It may be that this is something that can be generalized enough to fit with your approach.  My main concern in this regard is that we need to be able to update specific entries in the ELF image, as described above.

A related issue is that section loading can be refined with some ELF-specific details.  Some sections need to have memory allocated for their contents.  Other sections can be left in place in the originally generated image.  There is a good bit of unnecessary copying going on in the existing implementation, and I'm not clear to what extent your patch addresses that.  Before the object is loaded, it is copied into a new buffer and then the contents of each section are copied again as we go.  What I'd like is for the runtime loaders to use the buffer into which the object is originally generated and only make copies where it is strictly necessary.  This isn't necessarily something you need to do for your work to be acceptable, but I mention it as a likely next step.

Over the next few days I intend to apply your patch locally and try to merge our work into it.  I'll provide additional feedback as I get a better feel for what you've done.


From: llvm-commits-bounces at cs.uiuc.edu [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Danil Malyshev
Sent: Tuesday, February 07, 2012 12:24 PM
To: llvm-commits at cs.uiuc.edu
Subject: [llvm-commits] RuntimeDyLd new features

Hello everyone,

Please review the RuntimeDyLd-01.patch.
This patch makes the following changes:

1. The main works will made in the RuntimeDyLdImpl with uses the ObjectFile class. RuntimeDyLdMachO and RuntimeDyLdELF now only parses relocations and resolve it. This is allows to make improvements of the RuntimeDyLd more easily. In addition the support for COFF can be easily added.

2. Added ARM relocations to RuntimeDyLdELF.

3. Added support for stub functions for the ARM, allowing to do a long branch.

4. Added support for external functions that are not loaded from the object files, but can be loaded from external libraries. Now MCJIT can correctly execute the code containing the printf, putc, and etc.

5. The sections emitted instead functions, thanks Jim Grosbach. MemoryManager.startFunctionBody() and MemoryManager.endFunctionBody() have been removed.

6. MCJITMemoryManager.allocateDataSection() and MCJITMemoryManager. allocateCodeSection() used JMM->allocateSpace() instead of JMM->allocateCodeSection() and JMM->allocateDataSection(), because I got an error: "Cannot allocate an allocated block!" with object file contains more than one code or data sections.

7. Fixed ELF::R_X86_64_PC32 relocation for the case when RealOffset is negative value.

8. Added new testing folder: ExecutionEngine/MCJIT because mcjit tests can be running only for x86 and arm and it's can be filtered with dg.exp.

Tested in Ubuntu x86_64, Ubuntu armv7 and MacOS 64.

Thank you,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120209/ee6aad2e/attachment.html>

More information about the llvm-commits mailing list