[llvm-commits] [llvm] r148231 - in /llvm/trunk: lib/ExecutionEngine/RuntimeDyld/ test/ test/ExecutionEngine/ tools/lli/

[Eli Bendersky]

On Mon, Jan 16, 2012 at 21:29, Jim Grosbach <grosbach at apple.com> wrote:

> Sure thing. This is a bit rough around the edges, but should give the
> basic idea.
>
> The old JIT likes to think of things in terms of atoms that are functions,
> global values, etc.. The MCJIT doesn't have that level of granularity, and
> so that doesn't really fit well. Instead, it thinks of things in terms of
> sections, just like a non-JIT linker does. I'm planning on switching the
> allocation and relocation schemes in the JIT to do things on a section
> basis instead. This will do a few things:
>
> 1) start/end/extractFunction interfaces will be deprecated and be replaced
> by two allocation functions, one for executable sections and one for data
> sections.
> 2) reassignSymbolAddress() will be replaced by reassignSectionAddress().
> 3) Internally, the RuntimeDyld will track things by section rather than by
> function. There's still the usual lookup by name interfaces externally.
>
> I'll try to keep the changes I make to the ELF side as minimal as I can so
> you can move ahead with your patches w/o having to rework much as we  go.
> You can then move the ELF bits to the new schema afterwards. I don't
> anticipate it'll be all that disruptive, really, and should allow a much
> cleaner implementation than the current stuff.
>
> I hope to have the MachO side landed, at least partially, today or
> tomorrow so there will be real code to talk about rather than just
> hand-waving.
>
>
Jim, thanks for the explanation. I agree completely - we also felt that the
existing memory manager interfaces are un-natural for MCJIT and were
thinking of a replacement. It's great that you've considered this as well,
since we'll now be able to consolidate on a single solution for both MachO
and ELF.

I saw your commits, and we'll now study the new code and see how we use the
new interfaces to solve the problems we ran into with ELF dynamic loading.
I will also commit a few additional tests for test/ExecutionEngine, and see
if all our tests pass for MCJIT on ELF with your new interfaces (by default
"make check" in trunk still runs ExecutionEngine tests for JIT, not MCJIT,
though our committed changes allow to run them with with MCJIT using
llvm-lit).

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120117/5b6da30a/attachment.html>