[llvm-commits] RuntimeDyLd new features

[Danil Malyshev]

Hello Eli,

Oh, I did not see this patch as was very busy with my patch and did not follow the mailing. I apologize. Now I will study it.

> How does your patch relate to this work? It may be a good idea to discuss all the requirements and possible solutions and come up with a design that suits everyone. Otherwise it's hard to review and reason about several large & conflicting patches to the same area of code.

I can offer a few thoughts for discussion about the design:

The code should be emitted by sectors, rather than by functions.
If we allocate space for each function separately, there is no guarantee that their position relative to each other will be the same as it was in the object file. However, if two functions are in one sector and one calls the other, then this call will at once direct brunch in the code without any relocation. And if these two functions will be emitted separately, probably a runtime error will occurred.

RuntimeDyLdImpl
Simplistically, RuntimeDyLd doing the following:
1. Load an object file:
1.1. Parse an object file, finds the functions, data, relocations, etc.
1.2. Emit functions and data.
1.3. Parse relocations, associate it with the emitted data.
2. Resolve relocations after loading all the object files.
If we will parsing the object file with the ObjectFile class then the object file formats different will appear only at stages 1.3 and 2.
In this case, it makes sense to most of the work doing in RuntimeDyLdImpl, and only stages 1.3 and 2 doing in RuntimeDyLdMachO and RuntimeDyLdELF.

ARM
Some branch instructions have a limited range. For address outside this range are used special instructions. Accordingly, we need add a stub function with these instructions when we see short range branch relocation, because we can not be sure this brunch is out of range or not.
Perhaps another architectures need stub-functions also, so it is desirable to make this mechanism more general.

Regress tests.
The RuntimeDyLd has only x86 and ARM relocation resolvers now (in ToT ARM ELF not yet supported, but in any case, I'll add support for ARM ELF). So it make sense to use an separate folder for MCJIT ExecutionEngine tests and add to dg.exp a special filter.


Regards,
Danil

________________________________
From: Bendersky, Eli [mailto:eli.bendersky at intel.com]
Sent: Wednesday, February 08, 2012 10:00 AM
To: Danil Malyshev; llvm-commits at cs.uiuc.edu
Subject: RE: RuntimeDyLd new features

Hi Danil,

We're currently working on getting MCJIT running on ELF (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-January/046671.html), and a couple of patches were already committed. There's another patch, currently pending a review (http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120130/135997.html) with further changes that make MCJIT on ELF (Linux) pass 100% of ExecutionEngine tests (all the same tests JIT passes), as well as supporting MCJIT debugging with GDB.

How does your patch relate to this work? It may be a good idea to discuss all the requirements and possible solutions and come up with a design that suits everyone. Otherwise it's hard to review and reason about several large & conflicting patches to the same area of code.

Eli

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