[llvm-commits] [llvm] r128031 - in /llvm/trunk: include/llvm/ExecutionEngine/RuntimeDyld.h lib/ExecutionEngine/Makefile lib/ExecutionEngine/RuntimeDyld/ lib/ExecutionEngine/RuntimeDyld/CMakeLists.txt lib/ExecutionEngine/RuntimeDyld/Makefile lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp tools/llvm-rtdyld/Makefile tools/llvm-rtdyld/llvm-rtdyld.cpp

[Jim Grosbach]

OK. That's a significantly different proposition than just enabling debug info, though.

It'll certainly be possible to implement a RuntimeDyld for ELF. There would need to be some, probably triple based, selection logic of which Dyld to load and the MC-JIT would likewise need to switch which object streamer it creates. That should all be quite transparent to the overall architecture, though.

-Jim

On Mar 24, 2011, at 11:51 AM, Jan Sjodin wrote:

> I would like to use ELF as a container instead of MachO. If I remember correctly, the idea was that MC-JIT would be able to link in external object files. It might be possible to do with MachO as the container in memory, but it does not seem very clean. The idea was to have both MachO  and ELF MC-JITs.  Using ELF as the container makes registering with gdb very simple. What I did with JunkJIT works for my current needs, but I would prefer to move on to the ELF MC-JIT, since this is really the way forward and I don't have the same time restrictions anymore.
> 
> - Jan
> 
> From: Jim Grosbach <grosbach at apple.com>
> To: Jan Sjodin <jan_sjodin at yahoo.com>
> Cc: llvm-commits at cs.uiuc.edu
> Sent: Tue, March 22, 2011 4:59:27 PM
> Subject: Re: [llvm-commits] [llvm] r128031 - in /llvm/trunk: include/llvm/ExecutionEngine/RuntimeDyld.h lib/ExecutionEngine/Makefile lib/ExecutionEngine/RuntimeDyld/ lib/ExecutionEngine/RuntimeDyld/CMakeLists.txt lib/ExecutionEngine/RuntimeDyld/Makefile lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp tools/llvm-rtdyld/Makefile tools/llvm-rtdyld/llvm-rtdyld.cpp
> 
> No, but to be fair, that's not hooked up to work on a native MachO platform, either. :)
> 
> Since the debug info is DWARF in both cases, it's possible that a lot of things will just work without much, if any, ELF customization. There will still need to be gdb-specific hooks to register the info and EH frame, of course. I may be being overly optimistic, though.
> 
> -Jim
> 
> On Mar 22, 2011, at 1:48 PM, Jan Sjodin wrote:
> 
> > I was mainly thinking of debug info and being able to run gdb. Would that work?
> > 
> > - Jan
> > 
> > From: Jim Grosbach <grosbach at apple.com>
> > To: Jan Sjodin <jan_sjodin at yahoo.com>
> > Cc: llvm-commits at cs.uiuc.edu
> > Sent: Tue, March 22, 2011 4:32:34 PM
> > Subject: Re: [llvm-commits] [llvm] r128031 - in /llvm/trunk: include/llvm/ExecutionEngine/RuntimeDyld.h lib/ExecutionEngine/Makefile lib/ExecutionEngine/RuntimeDyld/ lib/ExecutionEngine/RuntimeDyld/CMakeLists.txt lib/ExecutionEngine/RuntimeDyld/Makefile lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp tools/llvm-rtdyld/Makefile tools/llvm-rtdyld/llvm-rtdyld.cpp
> > 
> > That depends on what you're looking to do. What specifically do you mean by supporting ELF? The code should work as-is on an ELF based system. It just needs the input object file to be a MachO.
> > 
> > Even as this gets fleshed out to handle more things, it's only at the edges where the JITed code interfaces with external bits that there's likely to be any extra work required to run on an ELF based system, and that should be relatively self-contained.
> > 
> > So if you mean whether this infrastructure should work on an ELF based host, then yes, at least most of it should work without modification. If you mean using ELF as a container instead of MachO, then no, I have no plans to do that.
> > 
> > -Jim
> > 
>