Hi list, The short version of my question: Is it easy to make a lightweight (read: small in size) linker loader for code produced by the llvm jit. Does it even make sense to do so? The longer version: Suppose I have some llvm bytecode module A, and I want to load and use that code in some runtime. The two obvious ways to do that are a) use the LLVM jit, or b) compile the module into a dynamic library and load it then. Option b, as I understand, doesn't work on Windows. Option a requires having the LLVM jit linked to the runtime. This seems reasonable, but as it turns out, the LLVM jit is several times larger than our runtime (yes, the Release version): ~5 M vs ~.5 M. Would it be possible (ie, relatively straitforward) to do the following: Take the code in module A, compile it with the JIT (since we cannot make libraries in Windows), and save the resulting binary goo in some file. Later (in a different instance of the runtime), with some much smaller sized loader, read in the file and link that code to the runtime. The platforms we care about this working on is the x86, ppc, and sparc v9. While it would be nice to be able to build a runtime that only contains the absolute minimal, this seems rather non-trivial, but maybe I am wrong. If this is indeed involved, fraught with danger (ie, would make it impossible to debug) etc, let me know as well.If there is some other clever (or obvious) way to accomplish the same thing, I'd love to hear any ideas. -- -Alex
On Mon, 16 May 2005, Alexander Friedman wrote:> Would it be possible (ie, relatively straitforward) to do the > following: Take the code in module A, compile it with the JIT (since > we cannot make libraries in Windows), and save the resulting binary > goo in some file. Later (in a different instance of the runtime), with > some much smaller sized loader, read in the file and link that code to > the runtime. The platforms we care about this working on is the x86, > ppc, and sparc v9.Yes, this would be straight-forward. The output of the code generator is a bunch of bytes of machine code and relocations to perform on it. This is exactly what you would need to do this.> While it would be nice to be able to build a runtime that only > contains the absolute minimal, this seems rather non-trivial, but > maybe I am wrong. If this is indeed involved, fraught with danger (ie, > would make it impossible to debug) etc, let me know as well.If there > is some other clever (or obvious) way to accomplish the same thing, > I'd love to hear any ideas.Another option might be to just fix building .dll's on windows :) -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/
>> While it would be nice to be able to build a runtime that only >> contains the absolute minimal, this seems rather non-trivial, but >> maybe I am wrong. If this is indeed involved, fraught with danger (ie, >> would make it impossible to debug) etc, let me know as well.If there >> is some other clever (or obvious) way to accomplish the same thing, >> I'd love to hear any ideas. > > Another option might be to just fix building .dll's on windows :)I will be working on a COFF backend after the NASMW one. Then possibly direct PE generation. Thats the plan anyway, if I can get the LLVM C++ frontend built otherwise I will have to skip doing that and use the older precompiled binary frontend. This is what is delaying me from getting on at the moment. Testing is going to be the biggy. Doing proper ABI support against MSC's calling conventions. Aaron
On May 16, Chris Lattner wrote:> On Mon, 16 May 2005, Alexander Friedman wrote: > > Would it be possible (ie, relatively straitforward) to do the > > following: Take the code in module A, compile it with the JIT (since > > we cannot make libraries in Windows), and save the resulting binary > > goo in some file. Later (in a different instance of the runtime), with > > some much smaller sized loader, read in the file and link that code to > > the runtime. The platforms we care about this working on is the x86, > > ppc, and sparc v9. > > Yes, this would be straight-forward. The output of the code generator is > a bunch of bytes of machine code and relocations to perform on it. This > is exactly what you would need to do this.It looks like I am going to wind up writing something like this. Will you guys accept a patch? It seems like the result will be a much-simplified version of the JIT/JIT.cpp and JIT/JITEmitter.cpp, as well as some utility to write the code and relocations into a file. There will also need to be a loader, which will depend on as little of the framework as possible. This seems fairly usefull - it breaks the reliance on the system assembler for dynamic systems. What do you guys think? -- -Alex