On Sun, Jun 13, 2010 at 4:43 PM, Nathan Jeffords <blunted2night at gmail.com> wrote:>> I know some people are working on native linkers for LLVM. It would be >> interesting to see an architecture for handling object files that >> could be shared between lib/MC and a linker. > > > This would be good I think. > If a linker loaded object files into an IR, maybe CAssembler could handle > the linking process also. Would it be safe to assume that on a > development/build machine, the executable image, and all the object files it > will be made up of could be loaded into memory in some IR? Or would an > architecture where the linker only reads headers and symbol information into > memory and then copies data sections into the final EXE on the fly?Considering how large object files can get, I would think it's not a good idea to load all the content of all the object files into an IR. However, the object file headers could be loaded into an IR that references the data still on disk, and then lazily load the data when it is time to insert relocations and write out the final executable. I would also assume that the linker should be able to accept llvm byte code and output an executable. In a pure llvm/clang tool chain there should be no reason to use native object files other than linking against code you only have in native format. And back to the topic at hand. I have attached tests that work with the changes Daniel made to lit. I switched to using llc and .ll files instead of llvm-mc and .s files due to the lack of COFF support in llvm-mc. - Michael Spencer -------------- next part -------------- A non-text attachment was scrubbed... Name: COFF-support-test.patch Type: application/octet-stream Size: 22499 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100613/b8eb300f/attachment.obj>
On Sun, Jun 13, 2010 at 2:56 PM, Michael Spencer <bigcheesegs at gmail.com>wrote:> On Sun, Jun 13, 2010 at 4:43 PM, Nathan Jeffords > <blunted2night at gmail.com> wrote: > >> I know some people are working on native linkers for LLVM. It would be > >> interesting to see an architecture for handling object files that > >> could be shared between lib/MC and a linker. > > > > > > This would be good I think. > > If a linker loaded object files into an IR, maybe CAssembler could handle > > the linking process also. Would it be safe to assume that on a > > development/build machine, the executable image, and all the object files > it > > will be made up of could be loaded into memory in some IR? Or would an > > architecture where the linker only reads headers and symbol information > into > > memory and then copies data sections into the final EXE on the fly? > > Considering how large object files can get, I would think it's not a > good idea to load all the content of all the object files into an IR. > However, the object file headers could be loaded into an IR that > references the data still on disk, and then lazily load the data when > it is time to insert relocations and write out the final executable. > > I would also assume that the linker should be able to accept llvm byte > code and output an executable. In a pure llvm/clang tool chain there > should be no reason to use native object files other than linking > against code you only have in native format. > > And back to the topic at hand. I have attached tests that work with > the changes Daniel made to lit. I switched to using llc and .ll files > instead of llvm-mc and .s files due to the lack of COFF support in > llvm-mc. > > - Michael Spencer >Nice, is their any dependencies besides python and a LLVM build enviroment? cygwin? MinGW? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100613/145f00ee/attachment.html>
On Sun, Jun 13, 2010 at 6:21 PM, Nathan Jeffords <blunted2night at gmail.com> wrote:> Nice, is their any dependencies besides python and a LLVM build enviroment? > cygwin? MinGW?For this test there are none. For other tests you need GnuWin32 tools from http://getgnuwin32.sourceforge.net (for grep and sed and such). - Michael Spencer